Getting policy and claim data out of Pier, the authorized way

Where Pier's records sit under Open Insurance Brasil

Brazil already has a regulated pipe for exactly this data. Open Insurance Brasil — the Sistema de Seguros Aberto, run by SUSEP under the CNSP — splits sharing into public product data and personal data, where personal data is defined to include customer registration, policies, certificates, contracts, tickets and the transactions tied to them. Phase 2, carrying that policyholder data under consumer consent, has been live since 2023; Phase 3, which adds service initiation including a claim-notification API, an endorsement API and a quote API, has been operating since 2024, per SUSEP's program pages and the Open Insurance developer area. Pier presents itself as a SUSEP-licensed digital insurer, which places its policyholder records inside that perimeter rather than outside it.

That changes the shape of the work. Instead of treating Pier as a closed app, we treat it as a participant in a consent regime whose data model and security profile are published. The bottom line: the durable way into a Pier policyholder's records is the Open Insurance consent flow, and we build the client, the schema mapping and the tests around that — with an authorized session route kept ready for fields the regulated APIs do not yet expose.

What Pier holds, per policyholder

These are the surfaces a Pier customer sees in the app, named the way Pier names them where it matters. Each maps to something an integrator would actually consume.

Routes into Pier's data we'd actually take

Open Insurance Brasil consent (the spine)

A consumer authorizes a SUSEP-accredited receiver; an OAuth 2.0 / FAPI authorization with a consent resource scopes which records and for how long, then the auto and financial-risk resource APIs return policy, contract and claim data. Reachable: registration, policies, contracts, claim tickets, and through Phase 3 the claim-notification path. Effort: moderate — the security profile and schema are published, the accreditation and the consent journey are what we set up with you. Durability: high, because it is mandated and versioned rather than incidental.

Authorized session analysis

For fields the regulated APIs do not yet surface — inspection photo state, the granular Pier Bolt decision timeline — we analyze the app's own authenticated traffic under your written authorization, document the auth and token chain, and build a typed client against it. Reachable: anything the app itself renders. Effort: higher and front-end-sensitive. Durability: medium; it is paired with the consent route so the regulated feed carries the stable core.

User-consented credential session

Where a customer explicitly consents, a session is established on their behalf and the same record set is read back. This is the lightest path for a single-tenant tool and the least durable; we use it to bridge a launch while the consent accreditation completes.

Our call: the Open Insurance consent route carries the policy, contract and claim core because it is the one designed to outlive app redesigns, and the session route rides alongside it only for the inspection and fine-grained reimbursement detail the regulated APIs have not reached. We say which fields land on which route in the handoff, so nothing is assumed.

A consent call against the policies resource

Illustrative shape — the consent grant, then a policy read. Field and path names follow the Open Insurance Brasil developer area; exact values are confirmed during the build.

# 1) Exchange the authorization code (OAuth2 / FAPI, mTLS) for a token
POST /open-insurance/authorise/token
  grant_type=authorization_code
  code=<auth_code>
  redirect_uri=<receiver_callback>
  client_assertion_type=...jwt-bearer
→ { "access_token": "...", "token_type": "Bearer", "expires_in": 900 }

# 2) Read the consented auto-policy record
GET /open-insurance/insurance-auto/v1/insurance-auto/{policyId}/policy-info
  Authorization: Bearer <access_token>
  x-fapi-interaction-id: <uuid>
→ 200 {
     "data": {
       "documentType": "APOLICE_INDIVIDUAL",
       "policyId": "...",
       "coverages": [ {"branch":"...", "code":"CASCO", "isDeductible":false} ],
       "insuredObjects": [ {"type":"VEHICLE", "identification":"<plate>"} ]
     }
   }

# Error handling we wire in:
#   401 -> token/consent expired   -> refresh via consent status, do not retry blind
#   403 -> consent scope mismatch  -> surface which permission group is missing
#   429 -> rate limited            -> honour Retry-After, backoff with jitter
#   claim/reimbursement records read on their own resource, joined by policyId
      

What you receive at handover

Everything is tied to Pier's real surfaces, not a generic insurer template.

• An OpenAPI 3.0 specification covering the consent grant, the policy and contract reads, the claim ticket resource and the reimbursement ledger as Pier exposes them.
• A protocol and auth-flow report: the OAuth 2.0 / FAPI consent chain for the regulated route, plus the token and session chain documented from the authorized analysis for the fallback.
• Runnable source for the key endpoints in Python and Node.js — consent bootstrap, policy and claim pull, reimbursement-status poll, pagination and the error handling shown above.
• Automated tests against recorded fixtures: consent expiry, scope-mismatch, a phone-claim lifecycle and a Pier Bolt payout transition.
• Interface documentation a non-author engineer can run from, plus consent-record and data-retention guidance aligned to LGPD and the Open Insurance consent model.

What we account for on a Pier build

Concrete things this app forces, all handled on our side as part of the work:

• Pier's two products do not share a schema. Per the app description, auto cover is regionally scoped (Belo Horizonte at present) and phone cover is device-model scoped (Samsung and iPhone). We carry product type, region and device identity as first-class fields so a customer with a phone policy and no eligible car is represented correctly instead of squeezed into one shape.
• The phone-claim path has external dependencies — an Anatel IMEI-block check and a police report feed the Pier Bolt decision, with reimbursement in roughly five business days and up to thirty under review, per Pier's help center. We model the claim ticket, its attachments and the payout as separate records with explicit status transitions so a slow review does not look like a failed read.
• Consent under Open Insurance is time-boxed and revocable by the consumer at any time. We design the sync around the consent-refresh window and treat revocation as a normal state, not an exception, so the integration does not silently expire.
• The session fallback is front-end-sensitive. We keep a revalidation step in maintenance so a change in the app's own screens is caught and corrected rather than quietly returning stale fields. Access for this is arranged with you during onboarding; the build runs against a consenting account or the consent sandbox.

Where integrators put this

• A broker or aggregator showing a client's Pier auto and phone policies next to other carriers, pulled under one Open Insurance consent.
• An SMB accounting tool reconciling recurring Pier premium debits against Pier Bolt reimbursements for a small fleet.
• A claims-orchestration product tracking a phone-theft claim — IMEI block, police report, payout state — and alerting when a review crosses its window.
• A personal-finance app flagging a coverage gap, such as a car that falls outside Pier's current regional auto cover, from the policy record.

Cost and how the build runs

Source for the Pier consent client, the OpenAPI specification and the test suite ship as a single handover; you pay from $300, after delivery, once you have checked it works against a consenting account. The other model is our hosted endpoints — you call them and pay per call, with nothing up front and no source to maintain yourself. Either way the cycle is one to two weeks, and you brief us with just the app name and the data you want out of it; accreditation, sandbox and compliance steps are arranged with you as part of the engagement. Start the conversation at /contact.html.

How this brief was built

Checked in May 2026 against Pier's store listing and help center for the in-app claim and reimbursement flow, and against SUSEP and Open Insurance Brasil program material for the consent regime, phase scope and security profile. Primary sources opened:

• SUSEP — Open Insurance program page
• Open Insurance Brasil — developer area
• Pier help center — claim and reimbursement steps
• Pier — Google Play listing (digital.pier)

Mapped by the OpenBanking Studio integration desk · May 2026.

Other Brazilian insurance apps in the same data space

Same category, similar policyholder-data shape — useful when one consent layer needs to span several carriers. Listed for ecosystem context only.

• Justos — auto insurer using telematics; holds driving-behaviour history alongside policy and claim records.
• Darwin Seguros — usage-based auto cover with monthly renewal; per-trip and premium-adjustment data behind the account.
• 88i Seguradora Digital — embedded device, accident and wallet cover for mobility and fintech ecosystems; policy and claim records per partner.
• Kakau — digital cover for phones and bicycles; accidental-damage and theft claim data per device.
• Youse — online auto, home and life policies; multi-line policy and billing data in one account.
• Azos — life insurance and protection; beneficiary, policy and premium records.
• BemMaisSeguro — electronics cover for phones, notebooks and tablets; device-bound policy and claim records.
• Porto Seguro — large incumbent with auto and assistance apps; broad multi-product policy, claim and assistance data.

Screens we mapped

Questions integrators ask about Pier

Does Open Insurance Brasil already cover Pier's policy and claim records?

Yes. Personal insurance data — registration, policies, certificates, contracts and claim tickets — sits inside Open Insurance Brasil's Phase 2 perimeter, which SUSEP has carried since 2023, with Phase 3 service APIs (claim notification, endorsement, quote) live since 2024. Pier is a SUSEP-licensed insurer, so its policyholder records fall under that consent regime. We build against the consent flow and the auto and financial-risk resource APIs.

Can you pull the Pier Bolt reimbursement status and the IMEI plus police-report claim flow?

Yes. Pier's help center describes the claim path as in-app: open the contract, choose to trigger the cover, then for a phone the IMEI block on Anatel and the police report feed the Pier Bolt reimbursement decision, paid in roughly five business days and up to thirty in review. We model the claim ticket, its document attachments and the reimbursement ledger as distinct records with status transitions so a downstream system can track each payout.

Pier only covers cars in Belo Horizonte and Samsung or iPhone devices — does that limit the integration?

It shapes the data model, not the integration. Per the app's own description, auto cover is geographically scoped and phone cover is device-model scoped, so eligibility and coverage fields differ by product. We carry product type, region and device identity as first-class fields so a consumer with a phone policy but no eligible car is represented correctly rather than forced into one schema.

If we only need claim-status sync for Pier policyholders, what is the smallest sensible build?

A scoped build covering authentication, the claim ticket resource and the reimbursement ledger, delivered as runnable source plus its tests, runs inside the one-to-two-week cycle. You can take that as source from 300 USD paid after delivery, or call it as a hosted endpoint per use. Tell us the data you need and we size it from there.