Acko

Acko is an Indian digital-first insurer. It is not a marketplace and sells no goods, so it produces no orders, listings, inventory or shipments. What it does have, and what makes it worth a page in a commerce reference, is a genuinely published embedded insurance API: an OpenAPI 3 specification served at acko.com, covering policy issuance, retrieval, endorsement and claims across credit, travel, gig, health, home, fire, cyber and electronics products. If you sell phones, laptops or appliances and want device protection attached at checkout, this is the interface, and it is better documented than most Indian marketplaces' seller APIs.

At a glance

What it is

Acko Technology and Services Limited, CIN U74110KA2016PLC120161, is the Bengaluru based holding company for Acko General Insurance Ltd and Acko Life Insurance Ltd. It sells car, bike, health, term life and travel insurance directly to consumers through its own app and site, and it sells embedded insurance to businesses through an enterprise arm.

The enterprise side is the relevant one. Acko's enterprise page claims over 400 partner brands and shows logos including Zepto, Cred, MakeMyTrip, Redbus and HDB Financial Services, and advertises a one day go-live. Its product lines for partners are group health, credit or loan protection, travel, gig workforce cover and electronic device protection. The device protection line is described as "In-store plan attachment and device coverage powered by custom tech", and is the one most likely to sit next to a commerce transaction.

Acko also operates ACKO Drive, a car buying site at ackodrive.com. That is genuinely commerce, but the site returns HTTP 403 to non-browser clients behind Cloudflare and could not be read for this page, and no dealer or partner API for it was found.

API access

The documentation is public and needs no login. The Redoc page at /enterprise/documentation/enterprise.html initialises against the spec at:

GET https://www.acko.com/enterprise/documentation/open-api/issuance_endorsement_claims

That URL returns the raw OpenAPI 3.0.1 document, roughly 350 KB, titled "Acko for Enterprise API Documentation", with 28 path entries. Everything in this page comes from it, read on 2026-09-22.

Credentials do not. The enterprise pages offer "Talk to us", "Book a demo" and "Build custom plan" and nothing else, so a client_id and client_secret come out of a commercial conversation. Expect the usual insurance distribution paperwork alongside it, since distributing insurance in India is a regulated activity.

The specification's own overview states the versioning position plainly: "The APIs are further sub-divided into two versions V1 and V2. While we support both versions, we encourage you to go ahead with integrating with our V2 APIs". Build on V2.

Authentication

OAuth 2.0 client credentials against what is unmistakably a Keycloak deployment: the token path is /realms/partnership/protocol/openid-connect/token.

1. Obtain client_id and client_secret from Acko during onboarding.
2. Call the token endpoint. The specification declares grant_type, client_id and client_secret as required query parameters, and also declares a required Authorization header on the same operation. That combination is unusual, and Keycloak conventionally takes these as form-encoded body parameters with HTTP Basic in the header. Confirm the exact form with Acko before writing the client; the specification is ambiguous here and is the kind of detail a generated document gets wrong.
3. Send the resulting token in the Authorization header on every other call. Every single operation in the specification declares Authorization as a required header parameter, and there is no securitySchemes block at all, so the spec carries authentication as an explicit parameter rather than as a scheme.

POST /realms/partnership/protocol/openid-connect/token?grant_type=client_credentials&client_id=YOUR_ID&client_secret=YOUR_SECRET HTTP/1.1
Host: <base url supplied by Acko>
Authorization: <as agreed with Acko>

The specification documents only 200 and 401 responses for this operation and does not state the token lifetime, so the refresh interval has to come from the token's own expires_in. A credential store should hold client_id, client_secret and a cached token with its expiry, refreshing on expiry rather than on a fixed schedule. Multi-account is per partner: the partner identity is baked into the credential and also appears as a {partner} path segment on the V1 endpoints.

GET /external/partnership/policy?plan_id=PLAN123&policy_number=POL987 HTTP/1.1
Host: <base url supplied by Acko>
Authorization: Bearer <access token>

Objects we can read

Acko has no orders, order items, products, listings, inventory, shipments or locations. It has policies and claims. Those are the two ### sections that apply.

Policies

GET /external/partnership/policy, operation getPolicy.

Required query parameters: plan_id and policy_number. Required header: Authorization. There is no list endpoint and no date-window filter, which is the single biggest operational constraint on this API: you can only fetch a policy you already know the number of. Your own database is the index.

The response schema, IssuanceResponse, is the same object returned by every issuance call:

{
  "policy_id": "…",
  "status": { "policy_status": "…", "parameters": {} },
  "order": {
    "order_id": "…",
    "proposal_id": "…",
    "proposal": {},
    "parameters": {},
    "status": {},
    "premium": {}
  },
  "parameters": {},
  "premium": {
    "net_premium": 0,
    "gross_premium": 0,
    "tax": 0,
    "discount": 0,
    "plan": [],
    "breakup": {}
  }
}

Note that parameters is typed as a free-form object on IssuanceResponse, on Status and on order. Product-specific detail lives in there, so store the whole response as raw JSON rather than trying to normalise it up front.

Claims

GET /partnership/claims/internet/list, operation getClaim.

Required: policy_number as a query parameter and Authorization as a header. Optional: page and page_size, both 32 bit integers. This is the only paginated endpoint in the specification, and it uses page numbers, not cursors.

The response is JarvisClaimsResponse with two fields: claims, an array, and latestClaimTrackingUrl. As with policies, claims are addressable only by policy number.

Endorsement results

Endorsement calls return EndorsementResponse, which is the richest object in the specification: endorsement_id, policy_id, policy_number, certificate_pdf, certificate_url, status, ekind, premium, refund_premium, previous_premium, plan_type, person, device, last_session_created_on. The device field is where an electronics policy's covered hardware appears, and certificate_url is what you surface to a customer.

Writing back: listings, price and stock

Not applicable. There is nothing to list, price or stock. What you write are policies, endorsements and claims.

Issuance

The V2 pattern collapses every product onto one path, POST /external/partnership/policy, with the product determined by the request body. The specification distinguishes these operations only by appending trailing spaces to the path key, an artefact of expressing overloaded operations in OpenAPI, and it means a naive code generator will produce one method for all of them or fail outright. Write the client by hand.

The V1 equivalents are separate paths carrying the partner in the URL: POST /product/{health_partners}/policies, POST /product/{gig_partners}/policies, POST /product/{credit_partners}/policies, POST /product/{house_partners}/policies, POST /product/{credit_life}/policies. Acko's own guidance is to prefer V2.

Request bodies are product-specific. The health V2 body, PartnershipOneHealthPolicyRequestDTO, has three top-level fields: order, parameters and premium, which mirrors the response shape. The electronics V2 operation declares a JSON body with no schema reference in the published spec, so its fields are not documented publicly and must come from Acko. That is a real gap for the exact use case a commerce integrator cares most about.

All issuance calls return IssuanceResponse on 200 and declare 400, 401, 403, 409, 429, 500 and 503. The 409 is worth designing for: it is the duplicate-issuance path.

Endorsements

POST /external/partnership/endorse/policy for V2, with the same trailing-space overloading, covering endorsePolicyCancellationV2, endorsePolicyRequestDependentUpdate, endorsePolicyRequestNomineeUpdate and endorsePolicyGIGSessionCreate. The V1 form is POST /product/{partners}/policies/{policyId}/endorsements.

The cancellation body, PartnershipCancellationRequestDTO, carries plan, partnerId, policyId, endorsementType, updatedOn and endorsements, with policyId and endorsements required. Cancellation returning refund_premium on the response is what lets you reconcile a cancelled policy against a refunded order.

Proposals

Credit life has a proposal lane ahead of issuance, including a bulk form: POST /product/{partner}/proposal-policies and PUT to update, plus POST and PUT on /product/{partner}/batch/proposal-policies for creditLifeBulkProposal and bulkUpdateCreditLifeProposal. These are the only batch endpoints in the specification.

Claims

POST /external/partnership/v1/claim, operation createClaim. Request fields on CreateClaimRequest: policy_number, cover_id, storage_group, claim_request_number, max_approved_amount, product_brand, is_internal, user_id, internal_user_email, idempotency_key. The response, ExternalCreateClaimResponse, is claim_request_number, machine_instance_id and re_directional_url.

Two things to note. First, idempotency_key is present, so retries are safe if you supply one, and you should. Second, re_directional_url means the claim journey continues in Acko's own web flow: you create the claim, then hand the customer to Acko. You do not run the claim yourself.

Webhooks and notifications

None. The specification contains no webhook, callback or subscription definition.

The substitutes Acko provides are URLs rather than events: re_directional_url on claim creation and latestClaimTrackingUrl on the claims list. For status, poll getClaim by policy number, and poll getPolicy for policy status.

A workable cadence, given no published limits: poll claims for policies with an open claim every few hours, and re-fetch a policy only on a state change you already know about, such as an order cancellation. There is no list endpoint, so there is no way to discover changes across the book; the poll set must come from your own records.

Rate limits and pagination

No rate limit numbers, headers or quota fields appear in the specification. What does appear is a documented 429 response on every operation, so throttling exists and is enforced. Back off on 429 and instrument from the first day.

Pagination exists on exactly one endpoint: getClaim, by page and page_size. Nothing else paginates because nothing else lists.

Mapping to the unified model

Acko produces none of the unified objects. The honest mapping is an attachment, not a translation.

Suggested extra table, since none of the above carries the useful part:

Gaps and open questions

• The production base URL. Not published. The spec's only server is an internal hostname. This is a blocker until onboarding.
• The token request form. The spec declares grant_type, client_id and client_secret as query parameters plus a required Authorization header, which contradicts normal Keycloak usage. One call with Acko settles it.
• The electronics issuance body. The operation most relevant to a commerce integrator has a JSON request body with no schema in the published spec. Everything else has one.
• Sandbox. Not mentioned anywhere in the specification or on the enterprise pages.
• Rate limits. A 429 is documented on every operation but no number is given.
• No list endpoints. Neither policies nor claims can be enumerated. If your records drift from Acko's, there is no published way to reconcile.
• Token lifetime and refresh. Not documented. Read expires_in and do not assume.
• ACKO Drive. The car buying arm is real commerce and was unreadable behind Cloudflare. Whether it has a dealer API is unknown and would be a separate page.
• Regulatory posture. Distributing insurance in India is regulated by IRDAI. An engineering integration does not by itself make you a lawful distributor, and that is a legal question, not a technical one.

Sources

• Acko for Enterprise API documentation, the Redoc page: acko.com/enterprise/documentation/enterprise.html
• The underlying OpenAPI 3.0.1 specification, downloaded in full on 2026-09-22, 28 path entries, the source for every endpoint, operation id, parameter, schema and response code quoted above, including the Keycloak token path, the IssuanceResponse and EndorsementResponse shapes, the CreateClaimRequest fields and the internal-hostname server block: acko.com/enterprise/documentation/open-api/issuance_endorsement_claims
• Acko enterprise landing page, for the 400 plus brands claim, the named partner logos, the product lines and the one day go-live claim: acko.com/gi/enterprise
• Acko electronic device insurance page, the source for "In-store plan attachment and device coverage powered by custom tech" and for the "Talk to us" and "Book a demo" onboarding route: acko.com/gi/enterprise/electronic-device-insurance
• Acko homepage, for the legal entity Acko Technology and Services Limited, CIN U74110KA2016PLC120161, and the group structure: acko.com
• ACKO Drive, which returned HTTP 403 behind Cloudflare to non-browser clients on 2026-09-22 and could not be read: ackodrive.com