Report problems in your shared Slack channel with the one identifier that makes your category diagnosable, because a report without it costs a round trip before anyone can look. For a regulatory or reporting question, lead with the deadline.
IB-specific escalation routes
Four categories reach a different person than an engineering question does. Name the category in your first line so the message is routed once rather than twice.
No out-of-hours or regulatory escalation path is published, and no response-time targets exist for
any severity.
Do not build an internal SLA, or a filing plan, on top of ours. Ask your integration lead to name
the escalation path and the out-of-hours route in writing, and pin it. If a report that carries a
regulatory deadline has had no reply, re-post it in the channel rather than waiting in the thread,
and tag your integration lead by name.
What to include on a regulatory or reporting question
One identifier per category does most of the diagnostic work. Include it in the first message.
Two rules that apply to every category:
- Quote errors verbatim, including the gRPC status code. An exchange-level rejection arrives as gRPC
OK with status = REJECTED, so “it failed” and “the RPC errored” are different reports with different causes.
- Name the environment in the first line. Several behaviours differ, and preprod has no status signal, so we cannot infer it.
Never put customer PII or SSNs in the shared channel, including for debugging. Quote the
external_id and the participantId instead. There is no published guidance on what an IB may
share about its own customers in a support channel.
Four current pages tell partners to quote correlation and workflow_id identifiers in a support
request, to a destination that is only an email address.Capture both if you have them and put them in your Slack message. Do not rely on an email route
reading them.
Severity
Say the severity in the first line. These are the categories we act on:
Where to check status first
status.polymarketexchange.com covers production. Check it before reporting a production incident, and quote it if it disagrees with what you see.
- There is no preprod status signal at all. No status page, no maintenance calendar, and no partner-checkable health endpoint.
GET /v1/health is not a usable liveness check.
It is documented as returning {"status":"ok"} with no auth, and partners have reported 404 in
production and 401 in preprod against it. Because you cannot check preprod yourself, report an
unexplained preprod failure with a timestamp and treat it as ours until shown otherwise.
Routes that are not yet defined
institutional@polymarket.us is the published route, and it is not the right route for a partner already live on preprod. Once you are integrating, your shared Slack channel is where work happens.
No page states the correct route for a partner already live on preprod.Ask your integration lead to name the route and the out-of-hours path in writing, and pin it in your
channel. Until that exists, the channel plus a named person is your only route.
There is no published intake route for a prospective partner, which has produced inbound from entities claiming agreements that do not exist. If you are asked to refer someone, refer them to your integration lead rather than to an address.
What can go wrong
Next
Reporting and bulk export