Skip to content

Invoice metadata#2

Open
kirushik wants to merge 3 commits into
gh-pagesfrom
feature/invoice-metadata
Open

Invoice metadata#2
kirushik wants to merge 3 commits into
gh-pagesfrom
feature/invoice-metadata

Conversation

@kirushik

Copy link
Copy Markdown
Member

For TiendaNube integration to work (as implemented in https://github.com/Kalapaja/konductor/pull/189), our daemons should support an opaque "metadata" field on orders.
This documents this extra API parameter as a part of v3 API spec

kirushik and others added 2 commits June 11, 2026 18:54
Stored verbatim, echoed in responses and webhook payloads, capped at
8192 bytes serialized; update replaces it (cart semantics). Matches the
daemon implementation.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
- Error schema required a phantom 'type' field it never defined and
  constrained 'category' to a 3-value lowercase enum the daemon doesn't
  emit. Now requires [code, message], 'category' is free-form (daemon
  emits SCREAMING_SNAKE) — making both the existing examples and the new
  metadata_too_large example valid.
- metadata is sticky on update (omitting keeps the stored value), must be
  a JSON object, and is stripped from the public payment-page endpoint —
  matching the daemon implementation.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Copilot AI review requested due to automatic review settings June 11, 2026 16:56

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Updates the Merchant API v3 OpenAPI spec to document an optional opaque metadata object on invoices/orders, supporting TiendaNube integration requirements.

Changes:

  • Adds metadata to the Invoice, CreateInvoiceRequest, and UpdateInvoiceRequest schemas with size/behavior notes.
  • Documents a new validation error example for oversized metadata (metadata_too_large / INVOICE_METADATA_TOO_LARGE).
  • Adjusts the Error schema documentation around error.category (now described as free-form).
Comments suppressed due to low confidence (1)

kalatori-merchant-api-v3.yaml:496

  • This example also uses type, while the Error schema defines error.category. Keeping examples consistent with the schema helps avoid ambiguity for integrators.
                  value:
                    error:
                      type: "invalid_request_error"
                      code: "validation_failed"
                      message: "Request validation failed"

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment thread kalatori-merchant-api-v3.yaml Outdated
Comment thread kalatori-merchant-api-v3.yaml
Comment thread kalatori-merchant-api-v3.yaml
Comment thread kalatori-merchant-api-v3.yaml
Address PR #2 review comments: replace the phantom `type`/`param`/
`validation_errors` fields and lower_snake codes in examples with the
`category` + SCREAMING_SNAKE `code` envelope the daemon actually emits,
document that update-not-allowed is a 409, and note explicitly that
`metadata` is always omitted from /public/invoice responses.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants