Obtain JWT tokens to authenticate all other requests.
ConnectPSP API (2.2.0)
ConnectPSP is a PIX payment gateway designed for high-throughput platforms such as digital wallets, betting companies, and fintechs.
This API allows you to:
- 💸 Receive payments via PIX (Cash-In) — standard QR Code or OpenFinance
- 🏦 Send payments via PIX key or bank account data (Cash-Out)
- 📊 Manage your wallet — check consolidated balances and rebalance between transactional and proprietary accounts
- 🪝 Receive real-time events via Webhooks as transactions progress
All endpoints (except POST /auth/token) require two headers:
| Header | Description |
|---|---|
Authorization | Bearer <jwt_token> — obtained from POST /auth/token |
ApplicationToken | Fixed GUID token that identifies your integration |
For financial operations (Cash-Out, Rebalance), an additional header is required:
| Header | Description |
|---|---|
DigitalSignature | HMAC-SHA256 hash of your JWT + CryptoToken. See Authentication Guide |
X-Idempotency-Key is optional on POST /cash-in and POST /cash-out, and recommended (a UUID v4 per operation). With it, a network retry returns the original response instead of creating a second transaction. Without it, the request is processed normally and externalReference still blocks duplicates with 409 DUPLICATED_EXTERNAL_REFERENCE. See the Authentication Guide for the full rules.
| Phase | What to confirm first |
|---|---|
| Setup | Credentials, environment, headers, and webhook readiness in Initial Setup |
| Authentication | JWT generation and DigitalSignature rules in the Authentication Guide |
| Transactions | Your first Cash-In or Cash-Out flow with idempotency and webhook validation |
PIX Health tells you whether PIX is working for you right now, and who is at fault when it is not.
A statistical engine compares every 5-minute window of your PIX traffic with what is normal for that weekday and time over the last four weeks, and attributes any clear deviation to the platform, to a settlement partner, to a payer bank or to your own operation — always scoped to what you actually use.
Three endpoints, all read-only and all safe to poll once a minute:
| Endpoint | Use it for |
|---|---|
GET /health/pix | The picture of the moment: status per block plus the incidents open right now |
GET /health/pix/incidents | History of confirmed incidents, paginated |
GET /health/pix/incidents/{id} | One incident with the evidence behind the verdict |
None of them require DigitalSignature or X-Idempotency-Key — only Authorization and ApplicationToken.
Confirmed incidents are also pushed as webhooks (PIX_INCIDENT_DETECTED / UPDATED / RESOLVED), so you do not have to poll to be warned; see the Webhooks guide.
Request
Returns the current picture of the PIX network as it affects your operation, in four blocks: platform (ConnectPSP), partners (the settlement partners you route through), banks (the banks your payers pay from and your payees receive at) and merchant (your own operation). Each block has a cashIn and a cashOut side with a health status and the verdict of every metric behind it — plus the confirmed incidents open right now.
The picture is produced every minute by our detection engine, which compares every metric of every 5-minute window with what is normal for that weekday and time of day over the last four weeks. Only a statistically clear deviation becomes an anomaly; the size of the drop sets the severity. It is cached for 60 seconds on our side, so polling once a minute is safe.
You only see what is in your scope. A partner you do not route through does not appear, and overallStatus is computed from your partners only: if a partner you do not use is degraded, your overall status stays HEALTHY. Banks appear only when your payers or payees use them. No platform volumes or other clients' data are ever included — only statuses and verdicts.
| Status | Meaning |
|---|---|
HEALTHY | Within the normal range for this weekday and time |
DEGRADED | Clearly worse, still working (for example, a 20 % drop in payments) |
SEVERELY_DEGRADED | Much worse — half or more of what should be happening is not |
UNAVAILABLE | Practically stopped |
UNKNOWN | Not enough sample in this window to say anything — not a failure |
ROUTED_AWAY | A partner with no traffic because volume was routed elsewhere — unknown, not down |
overallStatus is the worst of the ConnectPSP platform and your settlement partners, plus any confirmed incident on them. Payer banks and your own operation never downgrade it.
It is the single most misread value here, so to be explicit: UNKNOWN means the engine does not have enough evidence to judge, never that something is wrong.
Every verdict is a comparison against what is normal for that entity, on that weekday, at that time of day. Two things produce UNKNOWN:
- Too few operations in the window. Common on a quiet bank overnight, or on a low-volume one at any hour. Nothing is broken — there is simply not enough to measure.
- No baseline yet. The engine needs about four weeks of history for an entity before it can say what "normal" looks like. A bank it started watching recently reads
UNKNOWNuntil that history builds up.
Our own screens label this state "Calibrando" (calibrating) rather than "unknown", for the same reason. Treat it as "no reading", not as a red flag — and never as an outage.
Every cashIn / cashOut carries signals: the metric name and its verdict — NORMAL, LOW (below expected), HIGH (above expected) or UNKNOWN (no sample). For counts and success rates LOW is the bad side; for error rates and latencies HIGH is the bad side.
Do not confuse the two age fields — they answer different questions:
| Field | Question it answers |
|---|---|
generatedAt / stale | Is the picture itself fresh? stale: true means it is older than 3 minutes — the engine is late or stopped and we are still serving the last known payload |
dataFreshnessSeconds | How old is the newest traffic window behind it? Normally several minutes, because some metrics (such as CONVERSION_MATURED) only make sense after a QR code has had time to be paid |
So dataFreshnessSeconds: 480 together with stale: false is the normal case, not a contradiction: a fresh picture about a window that closed 8 minutes ago. Alert on stale, not on dataFreshnessSeconds.
This endpoint does not require DigitalSignature or X-Idempotency-Key.
- Staging Environment (Testing)https://api.homologacao.connectpsp.com/health/pix
- cURL
- JavaScript
- Node.js
- Python
- Java
- C#
- PHP
- Go
- Ruby
- R
- Payload
curl https://api.homologacao.connectpsp.com/health/pix \
-H "Authorization: Bearer <token>" \
-H "ApplicationToken: <app-token>"Picture returned successfully.
When the engine produced this picture (UTC).
Age of the newest 5-minute window the engine evaluated, in seconds.
true when the picture is older than 3 minutes — the engine is late or stopped, and the last known payload is still being served.
Health status. UNKNOWN means not enough sample to judge — never a failure. ROUTED_AWAY (partners only) means the partner has no traffic because volume was routed elsewhere.
The ConnectPSP platform as a whole. An operation is null when there is no data for it in the window.
The health of one operation (cash-in or cash-out) of one entity.
Health status. UNKNOWN means not enough sample to judge — never a failure. ROUTED_AWAY (partners only) means the partner has no traffic because volume was routed elsewhere.
Fraction of the metrics the engine could actually judge in this window (1 = all of them).
The health of one operation (cash-in or cash-out) of one entity.
Health status. UNKNOWN means not enough sample to judge — never a failure. ROUTED_AWAY (partners only) means the partner has no traffic because volume was routed elsewhere.
Fraction of the metrics the engine could actually judge in this window (1 = all of them).
The settlement partners in your scope: the ones you route through plus the ones you hold an active account with, even with no traffic of yours in the window. Use routing to tell them apart.
A partner you only hold an account with is reported with its real health, but it never affects your overallStatus and never raises an incident or a webhook for you.
"Active account" means an account seen in the last 30 days. Accounts are never deleted from our records, so a partner you stopped using more than 30 days ago drops off this list.
Are you routing through this partner in the current window?
true — your PIX traffic goes through it. It counts towards your overallStatus and can raise incidents and webhooks for you.
false — you hold an active account with it, but none of your PIX went through it in this window. The health reported here is the partner's real health, measured across the whole platform, so you can watch a partner you may switch back to at any time. It does not count towards your overallStatus, and it raises no incident and no webhook for you.
A partner you have not held an account with for over 30 days is not reported at all.
How much of your own PIX traffic was routed through this partner over the last 30 days, as a fraction between 0 and 1. Your number, not the platform's. 0 when there is no reading — the normal value for a partner with routing: false.
The health of one operation (cash-in or cash-out) of one entity.
Health status. UNKNOWN means not enough sample to judge — never a failure. ROUTED_AWAY (partners only) means the partner has no traffic because volume was routed elsewhere.
Fraction of the metrics the engine could actually judge in this window (1 = all of them).
The health of one operation (cash-in or cash-out) of one entity.
Health status. UNKNOWN means not enough sample to judge — never a failure. ROUTED_AWAY (partners only) means the partner has no traffic because volume was routed elsewhere.
Fraction of the metrics the engine could actually judge in this window (1 = all of them).
The banks your payers paid from, or your payees received at, over the last 30 days — crossed with the ones the engine watches. A bank you have not transacted with in 30 days is not listed.
The engine watches the 20 largest institutions by platform volume. Below that, an institution sends too few operations for any verdict to be meaningful, so it is left out rather than reported as permanently UNKNOWN.
Sorted worst-first, then by your own share, then by name.
How much of your own PIX traffic went through this bank over the last 30 days, as a fraction between 0 and 1. It is your number, not the platform's — we never report other merchants' volume.
Used to sort the list, and useful to weigh how much a given bank's health matters to you. 0 when there is no reading.
The health of one operation (cash-in or cash-out) of one entity.
Health status. UNKNOWN means not enough sample to judge — never a failure. ROUTED_AWAY (partners only) means the partner has no traffic because volume was routed elsewhere.
Fraction of the metrics the engine could actually judge in this window (1 = all of them).
The health of one operation (cash-in or cash-out) of one entity.
Health status. UNKNOWN means not enough sample to judge — never a failure. ROUTED_AWAY (partners only) means the partner has no traffic because volume was routed elsewhere.
Fraction of the metrics the engine could actually judge in this window (1 = all of them).
Your own operation, judged against your own history. null when you had no traffic in the window.
Your own operation, judged against your own history. null when you had no traffic in the window.
The health of one operation (cash-in or cash-out) of one entity.
Health status. UNKNOWN means not enough sample to judge — never a failure. ROUTED_AWAY (partners only) means the partner has no traffic because volume was routed elsewhere.
Fraction of the metrics the engine could actually judge in this window (1 = all of them).
The health of one operation (cash-in or cash-out) of one entity.
Health status. UNKNOWN means not enough sample to judge — never a failure. ROUTED_AWAY (partners only) means the partner has no traffic because volume was routed elsewhere.
Fraction of the metrics the engine could actually judge in this window (1 = all of them).
Confirmed incidents open right now on ConnectPSP or on your settlement partners.
Stable id. Use it to correlate the webhooks and the detail endpoint.
Who the incident is attributed to.
CONNECTPSP— the platform as a whole.BANKING_PARTNER— a settlement partner you route through (id= ISPB).PAYER_INSTITUTION— a bank your payers pay from / your payees receive at (id= ISPB).PAYER_COHORT— a group of payer banks with the same behaviour.MERCHANT— your own operation (id= your customer id).PIX_SYSTEMIC— the PIX system itself (DICT, SPI).
CASH_IN = payments you receive; CASH_OUT = withdrawals you send.
ACTIVE = confirmed and ongoing. WORSENING = severity went up. RECOVERING = metrics back to normal, waiting 3 windows to close. RESOLVED = closed.
How bad it is (never HEALTHY on an incident).
How sure the engine is about who is at fault — not about how bad it is.
How the engine knows. OBSERVED = it saw the error itself. INFERRED = deduced from the absence of what should have happened. CORROBORATED / CONFIRMED = backed by a second independent signal.
Start of the first anomalous window (UTC).
When the engine confirmed it (UTC).
When metrics returned to normal; null while ongoing.
When the incident was closed; null while open.
Diagnosis in Portuguese, written for you. Never contains other clients' data.
Confirmed incidents open right now on payer banks or on the PIX system itself. These are outside ConnectPSP's control and never downgrade overallStatus.
Stable id. Use it to correlate the webhooks and the detail endpoint.
Who the incident is attributed to.
CONNECTPSP— the platform as a whole.BANKING_PARTNER— a settlement partner you route through (id= ISPB).PAYER_INSTITUTION— a bank your payers pay from / your payees receive at (id= ISPB).PAYER_COHORT— a group of payer banks with the same behaviour.MERCHANT— your own operation (id= your customer id).PIX_SYSTEMIC— the PIX system itself (DICT, SPI).
CASH_IN = payments you receive; CASH_OUT = withdrawals you send.
ACTIVE = confirmed and ongoing. WORSENING = severity went up. RECOVERING = metrics back to normal, waiting 3 windows to close. RESOLVED = closed.
How bad it is (never HEALTHY on an incident).
How sure the engine is about who is at fault — not about how bad it is.
How the engine knows. OBSERVED = it saw the error itself. INFERRED = deduced from the absence of what should have happened. CORROBORATED / CONFIRMED = backed by a second independent signal.
Start of the first anomalous window (UTC).
When the engine confirmed it (UTC).
When metrics returned to normal; null while ongoing.
When the incident was closed; null while open.
How many settlement partners the incident reached.
Diagnosis in Portuguese, written for you. Never contains other clients' data.
{ "schemaVersion": 1, "generatedAt": "2026-09-08T16:53:00Z", "dataFreshnessSeconds": 480, "stale": false, "overallStatus": "HEALTHY", "platform": { "cashIn": { … }, "cashOut": { … } }, "partners": [ { … }, { … } ], "banks": [ { … }, { … } ], "merchant": { "id": "42", "name": "Your operation", "cashIn": { … }, "cashOut": { … } }, "incidents": [], "externalIncidents": [ { … } ] }
Request
Confirmed PIX incidents in your scope, most recent first, paginated. An incident is confirmed when the engine saw the same pattern in two consecutive 5-minute windows; a one-window blip never appears here. Defaults to the last 7 days; the window between from and to cannot exceed 92 days.
Each incident tells you who (origin), how bad (severity), how sure we are about the culprit (confidence) and how we know (originClass: OBSERVED = we saw the error, INFERRED = deduced from the absence of what should have happened). summary is a diagnosis in Portuguese written for you — never internal counts of other clients.
Unlike GET /health/pix, which splits the open incidents into incidents and externalIncidents, this list is flat. Use origin.type to tell the two apart: CONNECTPSP and BANKING_PARTNER are ours to fix, PAYER_INSTITUTION / PAYER_COHORT / PIX_SYSTEMIC are outside our control, and MERCHANT is your own operation.
status is matched case-insensitively, so active,worsening works too. The response echoes back the from and to actually applied, so you can log the window you really got.
This endpoint does not require DigitalSignature or X-Idempotency-Key.
- Staging Environment (Testing)https://api.homologacao.connectpsp.com/health/pix/incidents
- cURL
- JavaScript
- Node.js
- Python
- Java
- C#
- PHP
- Go
- Ruby
- R
- Payload
curl "https://api.homologacao.connectpsp.com/health/pix/incidents?status=ACTIVE,WORSENING&pageSize=20" \
-H "Authorization: Bearer <token>" \
-H "ApplicationToken: <app-token>"Page of incidents. items is an empty array when nothing matched — that is a normal, healthy answer, not an error.
Stable id. Use it to correlate the webhooks and the detail endpoint.
Who the incident is attributed to.
CONNECTPSP— the platform as a whole.BANKING_PARTNER— a settlement partner you route through (id= ISPB).PAYER_INSTITUTION— a bank your payers pay from / your payees receive at (id= ISPB).PAYER_COHORT— a group of payer banks with the same behaviour.MERCHANT— your own operation (id= your customer id).PIX_SYSTEMIC— the PIX system itself (DICT, SPI).
CASH_IN = payments you receive; CASH_OUT = withdrawals you send.
ACTIVE = confirmed and ongoing. WORSENING = severity went up. RECOVERING = metrics back to normal, waiting 3 windows to close. RESOLVED = closed.
How bad it is (never HEALTHY on an incident).
How sure the engine is about who is at fault — not about how bad it is.
How the engine knows. OBSERVED = it saw the error itself. INFERRED = deduced from the absence of what should have happened. CORROBORATED / CONFIRMED = backed by a second independent signal.
Start of the first anomalous window (UTC).
When the engine confirmed it (UTC).
When metrics returned to normal; null while ongoing.
When the incident was closed; null while open.
Diagnosis in Portuguese, written for you. Never contains other clients' data.
{ "items": [ { … }, { … } ], "total": 2, "page": 1, "pageSize": 50, "from": "2026-09-01T16:53:00Z", "to": "2026-09-08T16:53:00Z" }
Request
One incident with the evidence behind the verdict. Each piece of evidence names the metric, the entity, the relative deviation from expected and the Z-score — never raw platform volumes.
Returns 404 when the incident does not exist or is outside your scope; the two cases are deliberately indistinguishable.
This endpoint does not require DigitalSignature or X-Idempotency-Key.
- Staging Environment (Testing)https://api.homologacao.connectpsp.com/health/pix/incidents/{id}
- cURL
- JavaScript
- Node.js
- Python
- Java
- C#
- PHP
- Go
- Ruby
- R
- Payload
curl https://api.homologacao.connectpsp.com/health/pix/incidents/LIVE-202609081530-PAYER_INSTITUTION-00360305 \
-H "Authorization: Bearer <token>" \
-H "ApplicationToken: <app-token>"Incident and evidence.
Stable id. Use it to correlate the webhooks and the detail endpoint.
Who the incident is attributed to.
CONNECTPSP— the platform as a whole.BANKING_PARTNER— a settlement partner you route through (id= ISPB).PAYER_INSTITUTION— a bank your payers pay from / your payees receive at (id= ISPB).PAYER_COHORT— a group of payer banks with the same behaviour.MERCHANT— your own operation (id= your customer id).PIX_SYSTEMIC— the PIX system itself (DICT, SPI).
CASH_IN = payments you receive; CASH_OUT = withdrawals you send.
ACTIVE = confirmed and ongoing. WORSENING = severity went up. RECOVERING = metrics back to normal, waiting 3 windows to close. RESOLVED = closed.
How bad it is (never HEALTHY on an incident).
How sure the engine is about who is at fault — not about how bad it is.
How the engine knows. OBSERVED = it saw the error itself. INFERRED = deduced from the absence of what should have happened. CORROBORATED / CONFIRMED = backed by a second independent signal.
Start of the first anomalous window (UTC).
When the engine confirmed it (UTC).
When metrics returned to normal; null while ongoing.
When the incident was closed; null while open.
Diagnosis in Portuguese, written for you. Never contains other clients' data.
The anomalous points behind the verdict, newest first.
Start of the 5-minute window (UTC).
CASH_IN = payments you receive; CASH_OUT = withdrawals you send.
Who the incident is attributed to.
CONNECTPSP— the platform as a whole.BANKING_PARTNER— a settlement partner you route through (id= ISPB).PAYER_INSTITUTION— a bank your payers pay from / your payees receive at (id= ISPB).PAYER_COHORT— a group of payer banks with the same behaviour.MERCHANT— your own operation (id= your customer id).PIX_SYSTEMIC— the PIX system itself (DICT, SPI).
(observed − expected) ÷ expected. -0.16 means 16 % below expected. null when there is no expectation.
{ "incident": { "incidentId": "LIVE-202609081530-PAYER_INSTITUTION-00360305", "origin": { … }, "operation": "CASH_IN", "status": "ACTIVE", "severity": "DEGRADED", "confidence": "MEDIUM", "originClass": "INFERRED", "startedAt": "2026-09-08T15:30:00Z", "detectedAt": "2026-09-08T15:37:59Z", "recoveredAt": null, "resolvedAt": null, "updatedAt": "2026-09-08T16:52:00Z", "affectedPartners": 2, "summary": "Forte evidência de degradação em cobranças pagas por clientes da CAIXA ECONOMICA FEDERAL: a conversão desses pagadores ficou em 78,5%, contra 93,0% esperados, enquanto 9 instituições de controle seguem normais." }, "evidence": [ { … }, { … } ] }