← ComplianceCN

ComplianceCN market-access API docs

Free public beta. ComplianceCN is one market-access readiness workflow for AI agents, seller workflows and cross-border sellers. The first call already returns preliminary requirements you can show a seller. Stage 1 then interprets and saves the product profile. Stage 2 assesses evidence readiness. The seller then enters a mandatory secure human-review handoff, and Stage 3 releases the reviewer-signed practical next-step pack and any appropriate official/standardised form drafts only after sign-off.

Coverage means an operational module, not identical depth

Battery electronics, connected toys, cosmetics and food-contact goods each have a live structured module for the EU, UK, US and Australia: jurisdiction requirements, product questions, an evidence checklist and conditional rules. All 16 category-market modules and their current rules are source-checked. Evidence counts differ because the applicable obligations differ by product and market; agents can read the exact counts in the matrix.

ModuleMarketsEvidence checks per marketConditional rulesRule review
Battery electronicsEU, UK, US, AU6–913 unique; 4–6 per market13 source-checked
Connected toysEU, UK, US, AU8–1720 unique; 4–7 per market20 source-checked
CosmeticsEU, UK, US, AU3–711 unique; 5–7 per market11 source-checked
Food-contact goodsEU, UK, US, AU9–1324 unique; 6–14 per market24 source-checked

The canonical machine-readable matrix is returned by /api/v1/meta. Filtered cells are also returned by /api/v1/requirements, and MCP clients can call describe_coverage.

Machine-readable entry points

MCP access: free assessment, paid human review

  1. Call market_access_check with a plain-language message and no case_id. The first response already contains preliminary_requirements — interpreted category and markets, applicable requirements and an evidence checklist — which you can show the seller straight away. It is automatic and unreviewed, and carries a disclosure to relay with it.
  2. Every response carries exactly one next_action with literal arguments. Execute it as returned. Relay message, ask any questions by their stable key, and reply with market_access_check({case_id, answers:{<question.key>: <answer>}}). You never choose the next stage or rebuild the checklist.
  3. Keep the returned case_id for the same product. Stages 1 and 2 are free and unlimited: a different product simply starts its own case, and you can assess as many products as you like without payment.
  4. stage_1_processing and stage_2_processing are normal queued states, not errors. Keep the case ID, wait next_action.retry_after_seconds, then execute the returned next_action unchanged. Preliminary requirements are already available while they run.
  5. At stage_2_confirmation_required, present the provisional readiness result. If the seller supplies a correction, execute correct_stage_2; otherwise execute confirm_stage_2, which retrieves the secure email-and-consent page. It does not start review.
  6. At human_review_available, the next required step is a notification email and contact consent at action_url, then confirming that email. Review starts only after the emailed confirmation link is opened. Follow next_action.delegated_execution: complete the page when you hold the listed authority, otherwise present the URL.
  7. Stage 3 is never machine-generated. At stage_3_pack_ready, present the saved reviewer-signed pack and stop.
  8. The first human-reviewed pack is free per confirmed seller email. A second reviewed pack for the same email is arranged with ComplianceCN; the assessment itself stays free either way.
  9. describe_coverage, compare_market_requirements and watch_product_regulatory_changes need no case and no payment — they are computed from the published ruleset and answer on the first call.
1. market_access_check({ message: "Bluetooth speaker for Amazon Germany" })
   → { case_id: "ccase_…", state: "stage_1_processing",
       preliminary_requirements: {          // show this to the seller now
         provisional: true,
         interpretation: { reading: "…looks like battery-electronics for EU, UK.",
                           confidence: "high" },
         requirements_by_market: [ … ],
         evidence_checklist: [ … ],
         disclosure: { en: "Preliminary and automatic…", zh: "初步自动结果…" } },
       questions: [{ key: "category", ... }],
       next_action: { ... } }          // execute exactly as returned

2. market_access_check({
     case_id: "ccase_…",
     answers: { battery_type: "lithium_ion" }
   })
   → { state: "stage_1_ready", result: { product_profile: { ... } },
       next_action: { arguments: { action: "start_stage_2" } } }

3. market_access_check({
     case_id: "ccase_…",
     action: "start_stage_2"
   })
   → { state: "stage_2_needs_clarification" | "stage_2_confirmation_required",
       result: { ... }, next_action: { ... } }

4. market_access_check({
     case_id: "ccase_…",
     action: "confirm_stage_2"
   })
   → { state: "human_review_available", action_url: "https://…" }

5. After email confirmation and reviewer sign-off, resume the same case:
   market_access_check({ case_id: "ccase_…" })
   → { state: "stage_3_pack_ready", result: { ... } }

The server owns the saved Stage 1 profile, Stage 2 readiness result, review state and signed Stage 3 pack. Agents should never reconstruct the checklist, call hidden stage tools or skip the returned next_action. request_human_review exists only for older integrations; the primary MCP workflow uses the secure URL returned by market_access_check. describe_coverage and watch_product_regulatory_changes remain reachable outside the product-case gate.

Canonical workflow and public endpoint descriptions

  1. Stage 1: POST /api/v1/intake interprets the plain-language product profile.
  2. Stage 2: POST /api/v1/preflight performs the structured evidence/readiness assessment.
  3. Mandatory review: with explicit consent and a seller email, POST /api/consultancy/leads continues the same case into human review. MCP callers use the secure URL returned after confirm_stage_2.
  4. Stage 3: after review, an authenticated reviewer uses POST /api/consultancy/next-step-pack to prepare/edit the deliverable and signs it off. POST /api/v1/next-step-pack does not generate public pre-review drafts.
  5. After a usable product/market result, and with separate alerts consent, POST /api/alerts/checkout creates a Stripe free-trial subscription for reviewed changes that match that product.

GET requests to each path above return a safe endpoint description. The handoff GET is public and does not expose private lead records; an authenticated owner request is required to list leads.

Start with plain-language product information

This is the preferred first entry point for sellers and agents. Send product_description in ordinary language and optionally include temporary files. ComplianceCN first returns a provisional product classification—primary category, additional applicable modules, confidence, alternative hypotheses, reasons and missing facts—then fills its internal evidence checklist and separates confirmed gaps from unknown evidence. Sellers do not need to classify documents first.

curl -X POST "https://compliancecn.netlify.app/api/v1/intake" \
  -H "Content-Type: application/json" \
  -d '{"product_description":"Bluetooth children’s speaker with a rechargeable lithium battery, for Amazon Germany. Supplier sent a CE file and RoHS report.","language":"en"}'

Files sent to this automatic endpoint are processed temporarily and not stored by the endpoint. Extracted text and enabled image OCR may be processed by the configured SiliconFlow model. Agents that already extracted document text should send that text instead of uploading the file through chat.

Stage 2 structured alternative: evidence-readiness assessment

Use the structured endpoint when an agent already knows the product profile and target markets. It returns applicable rules, missing or unknown evidence, next actions and review gates. The response also includes suggested_evidence_testing_route: non-binding discussion suggestions that must not be presented as additional legal requirements.

curl -X POST "https://compliancecn.netlify.app/api/v1/preflight" \
  -H "Content-Type: application/json" \
  -d '{"category":"battery-electronics","markets":["EU"],"has_radio":true}'

Mandatory review and Stage 3 delivery

Stage 2 is a provisional evidence-readiness assessment. It does not release supplier requests, lab materials, marketplace-review routes, document indexes or official/standardised form drafts. The seller first confirms the Stage 2 result, provides an email with consent through the secure handoff, confirms that email, and sends the relevant original files. A reviewer then checks the product facts, document identity, model coverage, entities, signatures, evidence gaps and judgement points.

Only after reviewer sign-off does Stage 3 release the appropriate route and reviewed deliverables, which may include a bilingual supplier request, lab brief, marketplace submission index or prefilled form-field draft. The private /api/consultancy/next-step-pack endpoint is a reviewer workspace endpoint and requires owner authentication. The public /api/v1/next-step-pack endpoint returns human_review_required instead of generating a draft.

Optional continuation: product-specific change alerts

Use watch_product_regulatory_changes over MCP, or the REST endpoint below, only after the seller has a usable product and target-market profile. This is a recurring paid subscription with a free trial, not a free mailing list. The response returns a Stripe-hosted Checkout action. An agent may complete it only under a separate active payment mandate covering ComplianceCN and the displayed amount, currency and recurring terms; otherwise present the URL. Stripe may still require seller authentication.

curl -X POST "https://compliancecn.netlify.app/api/alerts/checkout" \
  -H "Content-Type: application/json" \
  -d '{"email":"seller@example.com","consent_to_alerts":true,"language":"en","product_profile":{"product_name":"Bluetooth speaker","category":"battery-electronics","markets":["EU"],"has_radio":true}}'

Only human-reviewed, explicitly alertable changelog entries are matched. A watch stores the email, minimized product/market profile, relevant result identifiers and Stripe/delivery state. It does not store uploaded documents or extracted document text. Alerts are a change-monitoring aid, not a complete legal surveillance service.

Required continuation: review by our team

For MCP, human review is a secure browser continuation rather than another agent tool. When market_access_check returns state: "human_review_available", inspect next_action.delegated_execution. An agent with the listed case-scoped authority may open the signed URL, use the seller's verified email and follow the confirmation message when it has those capabilities. Otherwise the seller completes the page. Review is not queued until the emailed confirmation link is opened.

Non-MCP clients can use the REST alternative below with explicit seller consent:

Boundaries

ComplianceCN provides market-access readiness checks using source-linked regulatory data and mandatory review by our team before Stage 3 is released. It is not legal advice, not certification, not product approval, and not a marketplace approval guarantee.

Read Trust & Methodology.