Skip to content

Getting provisioned with OpenAP

Access to the OpenAP eCAPI receiver is provisioned by OpenAP — there is no self-service signup. Integration begins with your OpenAP representative.

1. Contact OpenAP

Reach out to your OpenAP representative to begin onboarding. If you do not yet have one, contact OpenAP through your existing commercial relationship or via openap.tv.

During onboarding, OpenAP will work with you to establish:

  • Authentication credentials. OpenAP issues you an HMAC key ID and shared secret. See Authentication.
  • Your expected volume. So OpenAP can size infrastructure ahead of your traffic, complete the Expected load questionnaire — average and peak rates, batch sizes, and any planned spikes. Default rate limits (see API reference — Rate limits) cover most integrations; higher limits require review and are easiest to arrange during onboarding.
  • Data-processing terms. The applicable data-processing agreement is executed as part of onboarding, before production events are sent.

2. What you receive

At the end of onboarding you have everything needed to send events:

Item Description
data_set_id The destination namespace your events land in. Every event you send must carry a data_set_id you are authorized for.
HMAC credentials A key ID and a shared secret (see Authentication).
Production and test base URLs Confirmed at onboarding. See API reference — Endpoints.
Rate-limit overrides If your volume requires limits above the defaults — informed by your load questionnaire.

A request whose credentials are not authorized for the data_set_id in the payload is rejected with 401 Unauthorized. Authorization changes (including revocation) take effect within minutes without any change on your side.

3. Verify against the test endpoint

Before sending production traffic, verify your integration against the test endpoint (see API reference — Endpoints). It mirrors production behavior but writes to an isolated test data set. A recommended verification pass:

  1. Single event, success. Send one well-formed event; confirm 200 with { "accepted": 1 }.
  2. Batch, success. Send a wrapped events batch; confirm 200 with the full accepted count.
  3. Partial batch. Include one deliberately invalid event in a batch; confirm 207 and that your client correctly reads errors[].index and retries only the failed event after fixing it.
  4. Hashing. Send hashed identifiers computed by your production hashing code (not hand-made test values); confirm no hashed field validation errors. Verify against the worked examples in Hashing, consent, and privacy.
  5. Auth failure handling. Send one request with bad credentials; confirm your client surfaces the 401 rather than retrying it.
  6. Rate-limit handling. Confirm your client honors Retry-After on 429 with exponential backoff (you do not need to trigger a real 429 to verify this).

4. Go to production

Switch your sender to the production base URL and production credentials. Nothing else changes — the request format, payload schema, and response contract are identical between test and production.

Credential lifecycle

  • Shared secret: rotated on a 90-day cadence; rotation logistics are agreed at onboarding.
  • Revocation: authorization is checked on every request against OpenAP's records; revocation takes effect within minutes.

Support

Your OpenAP representative is the single point of contact for onboarding, credentials, data_set_id provisioning, rate-limit overrides, and base-URL confirmation.