Endpoints

ingest endpoint post /api/webhook/ingest/{ingest endpoint uuid} authentication bearer token in authorization header body json payload (see field mapping) rate limits default is 120 requests/minute responses 200 accepted request stored and queued for processing 422 unprocessable entity validation failed 401 unauthorized invalid/expired/missing token 429 too many requests rate limit exceeded global ingest endpoint post /api/webhook/ingest the global endpoint lets you send payloads for any of your ingest endpoints to a single url, without the endpoint uuid in the path instead of routing by url, jomablue resolves the target endpoint from an identifier included in the payload body this is useful when the sending system can only post to one fixed url but can vary the identifier per request identifier key by default the payload must include an ingest uuid field at the top level this key is configurable per instance, so confirm the exact key for your instance with jomablue identifier value may be either the ingest endpoint's uuid or its configured organisation uid authentication, rate limits, and responses identical to the standard ingest endpoint above once the endpoint is resolved, the payload is validated and queued in exactly the same way example payload { "ingest uuid" "123e4567 e89b 12d3 a456 426614174000", "contact" { "first name" "jane", "last name" "doe", "email" "jane doe\@example com" } } if the identifier is missing or does not match a known endpoint, the request is rejected with a 422 response missing identifier the provided payload does not include an ingest id the id should be provided in the node ingest uuid no match there is no match for the ingest id provided ingest test endpoint post /api/webhook/ingest/{ingest endpoint uuid}/test this validates a payload without persisting it use this to check whether a request would be accepted by the configured mapping and validation rules available only for people type ingesting validation ingest endpoints can be configured with customised schema validation this reduces bad data by rejecting invalid requests early if a request fails to pass validation, a 422 response is provided with some additional messaging { "message" "invalid", "success" false, "error type" "validation error", "errors" "the provided payload is not in the correct format for this endpoint" } considerations requests are processed asynchronously 200 accepted means queued, not processed no automatic deduplication; upstream systems should send unique identifiers (organisation uid) if required event ordering is not guaranteed; jobs are processed as picked from the queue people import type is labeled as ingest api in reporting so you can understand which records were ingested via this api the global endpoint (post /api/webhook/ingest) resolves the target endpoint from an identifier in the payload (default key ingest uuid, matching the endpoint's uuid or organisation uid) rather than from the url