Sends a notification to the table

post

{scheme}://{host}/{basePath}/v1/{prefix}/namespaces/{namespace}/tables/{table}/notifications

Recent Requests

Time	Status	User Agent
Retrieving recent requests…

Loading…

Path Params

prefix

string

required

An optional prefix in the path

namespace

string

required

A namespace identifier as a single string. Multipart namespace parts should be separated by the unit separator (0x1F) byte.

table

string

required

A table name

Body Params

The request containing the notification to be sent.
For each table, Polaris will reject any notification where the timestamp in the request body is older than or equal to the most recent time Polaris has already processed for the table. The responsibility of ensuring the correct order of timestamps for a sequence of notifications lies with the caller of the API. This includes managing potential clock skew or inconsistencies when notifications are sent from multiple sources.
A VALIDATE request behaves like a dry-run of a CREATE or UPDATE request up to but not including loading the contents of a metadata file; this includes validations of permissions, the specified metadata path being within ALLOWED_LOCATIONS, having an EXTERNAL catalog, etc. The intended use case for a VALIDATE notification is to allow a remote catalog to pre-validate the general settings of a receiving catalog against an intended new table location before possibly creating a table intended for sending notifications in the remote catalog at all. For a VALIDATE request, the specified metadata-location can either be a prospective full metadata file path, or a relevant parent directory of the intended table to validate against ALLOWED_LOCATIONS.

notification-type

string

enum

required

Allowed:

payload

object

required

Responses

204

Success, no content

400Indicates a bad request error. It could be caused by an unexpected request body format or other forms of request validation failure, such as invalid json. Usually serves application/json content, although in some cases simple text/plain content might be returned by the server's middleware.

401Unauthorized. The REST Catalog SHOULD respond with the 401 UnauthorizedResponse when the access token provided is expired, revoked, malformed, or invalid for other reasons. The client MAY request a new access token and retry the request.

403Forbidden. Authenticated user does not have the necessary permissions.

404Not Found - NoSuchTableException, table to load does not exist

409Conflict - The timestamp of the received notification is older than or equal to the most recent timestamp Polaris has already processed for the specified table.

419This is an optional status response type that the REST Catalog can issue when the token has expired. The client MAY request a new access token and retry the request. 401 UnauthorizedResponse SHOULD be preferred over this response type on token expiry.

503The service is not ready to handle the request, request could have been partially processed. The service may additionally send a Retry-After header to indicate when to retry, a non idempotent request should only be retried by the client when the Retry-After header is present.

5XXA server-side problem that might not be addressable from the client side. Used for server 5xx errors without more specific documentation in individual routes.