# Replace the India GST supplier registration `PUT /api/v1/india-gst/config` Replaces the supplier registration whole, creating it when the store has none. A FULL REPLACE. An omitted optional key is CLEARED, not carried over, and the five value fields are required rather than defaulted: a dropped enabled would take the merchant's invoicing down and a dropped default_rate_bps would read as 0 and tax every unclassified line at nothing, both with a 200 back. expected_updated_at IS REQUIRED and null is a legal value meaning "this store has no configuration yet". This row has more than one writer, and what a lost write costs here is not a wrong screen: the document is stamped onto every invoice issued afterwards. A mismatch is 409 config_modified. state_code AND created_by ARE REFUSED BY NAME. The state comes from the validated GSTIN, and the actor is the api key that made the call. ## Headers - `Idempotency-Key` (string, required) — A unique key per logical write. Replaying a request with the same key returns the first response byte for byte instead of applying the write twice. ## Request body Required. - `gstin` (string, required) — The 15-character registration, for example 27AAPFU0939F1ZV. Validated for structure, GST state and the mod-36 check digit, and stored upper-cased. Its first two digits become state_code. - `legal_name` (string, required) — The registered entity name that prints on the invoice, which is often not the store's trading name. - `address_line1` (string) — Registered address. Optional, and CLEARED when omitted. - `address_line2` (string) — Registered address. Optional, and CLEARED when omitted. - `city` (string) — Registered address. Optional, and CLEARED when omitted. - `postal_code` (string) — Registered address. Optional, and CLEARED when omitted. - `default_rate_bps` (integer, required) — The rate applied to a line whose product carries no HSN classification, in BASIS POINTS: 18% is 1800, never 18. Zero is legal and means unclassified lines are taxed at nothing. - `invoice_prefix` (string, required) — 1 to 6 uppercase letters or digits, leading every generated invoice number (INV in INV/252600001). Changing it renumbers nothing already issued, so a store's history can carry more than one prefix. - `enabled` (boolean, required) — The master switch. false refuses every issue with 409 gst_disabled and keeps every other field, which is the reversible operation this family offers instead of a delete. - `expected_updated_at` (string | null (date-time), required) — The updated_at you read from GET /api/v1/india-gst/config, or null if you expect this store to have no configuration yet. Anything else is 409. ## Responses - `200` — Success - `400` — The request was refused before any state changed. `code` is one of: `invalid_body`, a write body this route will not take. `reason` partitions it and `field` names the key when one key is at fault. `invalid_query`, a query parameter, including limit and after. `invalid_text`, a NUL byte or bytes that are not valid UTF-8 anywhere in the path, the query or the body. Strip control characters before sending. `idempotency_key_required`, a write sent without the Idempotency-Key header. `invalid_request`, an Idempotency-Key longer than 255 bytes. Routes add their own codes for rules only they know. Switch with a default arm. - `401` — No credential, or one this API does not accept. `code` is always `unauthorized`. THE BODY IS DELIBERATELY UNINFORMATIVE. An expired key, a revoked key, a publishable key, a key belonging to another merchant and a key that never existed are all refused with the same bytes, so this response cannot be used to probe which keys exist. Check the key's state in the dashboard rather than inferring it here. Send the key as `Authorization: Bearer ` or as `X-API-Key: `. It is never accepted in a query string. - `403` — The key lacks the write_india_gst scope. `code` is `insufficient_scope` and the message names the scope to ask the merchant for. - `409` — The request is well formed and the store's current state refuses it. EVERY WRITE CAN ANSWER TWO OF THESE, whatever it does: `idempotency_key_reused`, this Idempotency-Key already served a different method, path or body. The key namespace is per store and not per endpoint, so a key built from a business id collides across routes; use a fresh key per logical write. `idempotency_key_in_progress`, an identical request is still running. Retry after a short delay; exactly one of the racing calls will have applied. `not_configured` means the merchant has not set something up yet, with `resource` naming what. The remaining codes are the per-route state rules named on the operation. - `413` — The request body exceeded the cap named in the message. `code` is `payload_too_large`. Nothing was read and nothing was recorded, so the same Idempotency-Key may be reused once the body is smaller. - `415` — The body was not declared as `application/json`. `code` is `unsupported_media_type`. This API reads ONE media type. The `+json` structured suffixes are refused too, because they name semantics (merge-patch in particular) this API does not implement, and reading such a body as plain JSON would be a silent misreading. A write that carries NO body needs no Content-Type at all. - `422` — An id INSIDE the request resolves to nothing on this store. `code` is `unprocessable_reference`, `resource` names the kind of thing that did not resolve and `field` names where it arrived, so the fix is mechanical. Distinct from 404, which is about the url, and from 400, which is about the bytes. The message stays generic about WHY the id did not resolve: an id owned by another merchant must read identically to one that never existed. - `429` — Too many requests. `code` is `rate_limited`. Two limits apply independently: one on the credential and the route family, one on the client address. The headers describe whichever has less left, so honouring Retry-After always clears the window that bound. - `default` — Any status this operation does not list, in the same envelope. A 5xx means the request may or may not have applied. Retry it with the SAME Idempotency-Key: that is the only way to find out without risking a duplicate, and it is what the key is for. A few 4xx conditions arrive here rather than as a listed status because they depend on the merchant's plan or on a module being wired: 402 when a quota or a plan limit is reached, and 503 when a capability the route needs is not configured on this deployment. Both carry a `code` naming which. ## Example ```bash curl --request PUT \ --url 'https://api.mercemur.com/api/v1/india-gst/config' \ --header 'Authorization: Bearer ' ```