Meykt API

The Meykt API connects your own system — ERP, shop, or in-house software — to your Meykt organization. Orders go in, including personalization fields and production files; order and production status comes back out, either by polling or by webhook. It is a versioned REST API over JSON, authenticated with API keys that carry explicit permission scopes.

Working with an AI assistant?

Copy the instruction below and send it to your AI agent. It then knows what to build and where to find everything it needs — you do not have to read the rest of these docs.

You are connecting my system to Meykt (https://meykt.com), a production platform for personalized manufacturing. Build the integration for me.

Read this first. It is the complete API documentation in one file:
https://www.meykt.com/llms-full.txt

Machine-readable specification (use it to generate the client, do not transcribe endpoints by hand):
https://api.meykt.com/v1/openapi.json

What to build:
1. Send my orders to Meykt: POST /v1/orders with items, personalization fields and prices. Production files (engraving files, images) go through POST /v1/uploads first; reference the returned upload_id in the order.
2. Receive status back: register a webhook endpoint (POST /v1/webhook-endpoints) if my system can accept inbound HTTPS, and verify the X-Meykt-Signature header on every delivery. If my system is not reachable from the internet, poll GET /v1/orders?updated_since=<last poll> instead.

Rules you must respect — all of them are explained in the documentation:
- Use my own order number as external_order_id. Repeating an identical request is safe and never creates a duplicate order.
- Order creation is all-or-nothing. A 422 lists every field error at once; fix them all and resend the complete order.
- A 409 means the same order number already exists with different content. Never invent a new order number to work around it.
- Start with a test key (mk_test_). Test orders appear in the dashboard but never enter production.
- Warnings are not errors: an unknown SKU is accepted and reported, not rejected.
- Treat unknown status values and unknown response fields as unknown, never as an error.

Before you write code, ask me for: my Meykt API key, and which of my systems should send the orders. Do not guess field names or endpoints — everything is in the documentation above.

Not using an AI assistant, or want to know what your agent will do?

The instruction points your agent at two machine-readable sources. llms-full.txt is this entire documentation in a single plain-text file — quickstart, request and response shapes, every limit, the full error catalog, the file upload flow and the webhook signature scheme. openapi.json is the formal specification of every endpoint, generated from the live code, so a client generated from it cannot drift from what the API actually accepts.

Every page here is also available as raw Markdown by appending .md to its URL, for example https://www.meykt.com/developers/orders.md. Nothing on these pages is rendered by JavaScript, so an agent that simply fetches a URL sees exactly what a person sees.

Prefer to build it yourself? Start with the quickstart — an API key and a first order take about ten minutes.

#Base URL

All endpoints live under a single versioned base URL:

text

https://api.meykt.com/v1

The version is part of the path. Fields may be added to /v1 responses at any time; fields are never removed or redefined without a new version prefix.

#Authentication

Send your API key in the Authorization header on every request — never as a URL parameter, because URLs end up in logs and browser history.

bash

curl https://api.meykt.com/v1/ping \
  -H "Authorization: Bearer mk_test_YOUR_KEY"

Keys are created in the Meykt dashboard and exist in two environments: mk_test_ keys create orders that are visible in the order list but never enter production, and mk_live_ keys create real orders. Every rejection of a key — missing, unknown, revoked, or expired — returns the same error, invalid_api_key with HTTP 401. Scopes are orders:read, orders:write, files:write and webhooks:manage; there is no hierarchy, so orders:write does not imply orders:read. Details: Authentication.

#Rate limits

Each API key is limited to 120 requests per minute. Every authenticated response carries X-RateLimit-Limit, X-RateLimit-Remaining and X-RateLimit-Reset. When the limit is exceeded the API returns HTTP 429 with the error code rate_limited and a Retry-After header. Prefer one list call with updated_since over many single-order lookups.

#Compatibility promise

Write your integration so that it survives additive changes. Three rules apply:

Ignore unknown response fields. New fields can appear in any /v1 response. A client that rejects unknown keys will break on an ordinary, non-breaking update.
Treat unknown status values as "unknown". New status values can be introduced. Map values you know, pass through the rest, and never crash on an unrecognized status.
Nothing is removed without a new version. Existing fields will not be deleted or given a different meaning inside /v1. A breaking change ships as a new version prefix. Error codes are permanent and are never renamed.

#For AI agents

This documentation is designed to be read by machines, not only by people. An agent can build a complete Meykt integration from these three resources:

Resource	URL	Contents
Full documentation	`https://www.meykt.com/llms-full.txt`	Every developer page concatenated into one plain-text file
Machine specification	`https://api.meykt.com/v1/openapi.json`	OpenAPI description generated from the live endpoint registry
Markdown twin of any page	`https://www.meykt.com/developers/orders.md`	Append `.md` to any documentation URL to get raw Markdown instead of HTML

A single fetch of llms-full.txt is enough to write the whole integration. It contains the quickstart, the request and response shapes, all limits, the complete error catalog with remedies, the duplicate-protection semantics, the file upload flow and the webhook signature scheme. No HTML parsing and no crawling of individual pages is required.

bash

curl -s https://www.meykt.com/llms-full.txt
curl -s https://api.meykt.com/v1/openapi.json
curl -s https://www.meykt.com/developers/orders.md

openapi.json is the canonical machine-readable source for paths, methods, required scopes and schemas — generate clients from it rather than transcribing endpoint tables by hand. Error codes returned by the API carry a doc_url that points at the matching page under /developers/errors/<code>.

#Pages

Quickstart — from creating a key to a first order visible in the dashboard, including the safe-retry behavior.
Authentication — keys, scopes, test versus live environment, rate limits.
Orders — creating orders with personalization, duplicate protection via external_order_id, warnings, limits, listing and polling with updated_since.
Files — the two-step upload flow, accepted file types, size limits, expiry of unreferenced uploads.
Webhooks — event types, envelope, X-Meykt-Signature verification, retry schedule, automatic disabling.
Errors — every stable error code with cause and remedy.

#What this API does not do

Stated explicitly so that no integration is built on an assumption:

No modification of orders already sent. Once an order has been accepted, its content cannot be changed through the API. Sending the same external_order_id with different content returns HTTP 409 order_already_exists_with_different_content; existing data is never overwritten. Corrections are made in the Meykt dashboard.
No deletion of orders. There is no endpoint to delete or purge an order.
No shipped event. Meykt has no shipping flow, so no shipping webhook and no shipping status exist. The available events cover order receipt, production start, production completion, production failure, cancellation and item completion.
No tax calculation and no invoicing. Unit prices you send are net values; total_amount is the gross amount your customer paid and is carried for display only. Meykt neither computes tax nor produces invoices.
No partial order acceptance. Order creation is all-or-nothing: one invalid item rejects the entire order with HTTP 422 validation_failed, listing every field error at once.

Meykt API

Working with an AI assistant?

Copy the instruction below and send it to your AI agent. It then knows what to build and where to find everything it needs — you do not have to read the rest of these docs.

You are connecting my system to Meykt (https://meykt.com), a production platform for personalized manufacturing. Build the integration for me.

Read this first. It is the complete API documentation in one file:
https://www.meykt.com/llms-full.txt

Machine-readable specification (use it to generate the client, do not transcribe endpoints by hand):
https://api.meykt.com/v1/openapi.json

What to build:
1. Send my orders to Meykt: POST /v1/orders with items, personalization fields and prices. Production files (engraving files, images) go through POST /v1/uploads first; reference the returned upload_id in the order.
2. Receive status back: register a webhook endpoint (POST /v1/webhook-endpoints) if my system can accept inbound HTTPS, and verify the X-Meykt-Signature header on every delivery. If my system is not reachable from the internet, poll GET /v1/orders?updated_since=<last poll> instead.

Rules you must respect — all of them are explained in the documentation:
- Use my own order number as external_order_id. Repeating an identical request is safe and never creates a duplicate order.
- Order creation is all-or-nothing. A 422 lists every field error at once; fix them all and resend the complete order.
- A 409 means the same order number already exists with different content. Never invent a new order number to work around it.
- Start with a test key (mk_test_). Test orders appear in the dashboard but never enter production.
- Warnings are not errors: an unknown SKU is accepted and reported, not rejected.
- Treat unknown status values and unknown response fields as unknown, never as an error.

Before you write code, ask me for: my Meykt API key, and which of my systems should send the orders. Do not guess field names or endpoints — everything is in the documentation above.

Not using an AI assistant, or want to know what your agent will do?

Prefer to build it yourself? Start with the quickstart — an API key and a first order take about ten minutes.

#Base URL

All endpoints live under a single versioned base URL:

text

https://api.meykt.com/v1

The version is part of the path. Fields may be added to /v1 responses at any time; fields are never removed or redefined without a new version prefix.

#Authentication

Send your API key in the Authorization header on every request — never as a URL parameter, because URLs end up in logs and browser history.

bash

curl https://api.meykt.com/v1/ping \
  -H "Authorization: Bearer mk_test_YOUR_KEY"

#Rate limits

#Compatibility promise

Write your integration so that it survives additive changes. Three rules apply:

Ignore unknown response fields. New fields can appear in any /v1 response. A client that rejects unknown keys will break on an ordinary, non-breaking update.
Treat unknown status values as "unknown". New status values can be introduced. Map values you know, pass through the rest, and never crash on an unrecognized status.
Nothing is removed without a new version. Existing fields will not be deleted or given a different meaning inside /v1. A breaking change ships as a new version prefix. Error codes are permanent and are never renamed.

#For AI agents

This documentation is designed to be read by machines, not only by people. An agent can build a complete Meykt integration from these three resources:

Resource	URL	Contents
Full documentation	`https://www.meykt.com/llms-full.txt`	Every developer page concatenated into one plain-text file
Machine specification	`https://api.meykt.com/v1/openapi.json`	OpenAPI description generated from the live endpoint registry
Markdown twin of any page	`https://www.meykt.com/developers/orders.md`	Append `.md` to any documentation URL to get raw Markdown instead of HTML

bash

curl -s https://www.meykt.com/llms-full.txt
curl -s https://api.meykt.com/v1/openapi.json
curl -s https://www.meykt.com/developers/orders.md

#Pages

Quickstart — from creating a key to a first order visible in the dashboard, including the safe-retry behavior.
Authentication — keys, scopes, test versus live environment, rate limits.
Orders — creating orders with personalization, duplicate protection via external_order_id, warnings, limits, listing and polling with updated_since.
Files — the two-step upload flow, accepted file types, size limits, expiry of unreferenced uploads.
Webhooks — event types, envelope, X-Meykt-Signature verification, retry schedule, automatic disabling.
Errors — every stable error code with cause and remedy.

#What this API does not do

Stated explicitly so that no integration is built on an assumption:

No modification of orders already sent. Once an order has been accepted, its content cannot be changed through the API. Sending the same external_order_id with different content returns HTTP 409 order_already_exists_with_different_content; existing data is never overwritten. Corrections are made in the Meykt dashboard.
No deletion of orders. There is no endpoint to delete or purge an order.
No shipped event. Meykt has no shipping flow, so no shipping webhook and no shipping status exist. The available events cover order receipt, production start, production completion, production failure, cancellation and item completion.
No tax calculation and no invoicing. Unit prices you send are net values; total_amount is the gross amount your customer paid and is carried for display only. Meykt neither computes tax nor produces invoices.
No partial order acceptance. Order creation is all-or-nothing: one invalid item rejects the entire order with HTTP 422 validation_failed, listing every field error at once.