POS operations guide
Swiggy and Zomato POS integration: verify the connector before rollout
Posnic v1.3.0 does not contain a verified native Swiggy or Zomato connector. Use this guide to separate a controlled manual transfer from a formally approved platform integration and to retain evidence for every menu, order, kitchen, failure and reconciliation state.
Evidence and review scope
Evidence reviewed 2026-08-20. Owner-supplied Search Console query evidence, a structured scan of 2,979 tracked readable files, the published 430-path OpenAPI description, the pinned sale model and routes, 17 selected route and sales call-path tests, current official Zomato integration documentation, selected official Swiggy restaurant-partner sources and primary retry, API-security and recovery guidance.
Stable release: v1.3.0, source commit b531ef4. No native Swiggy or Zomato connector, branded webhook, external-order identity, idempotency control, vendor approval, platform agreement, load result, live restaurant mapping, complete integrated order or customer deployment was verified.
What the current evidence establishes
Search demand is real but small and query-only
Four direct rows supplied 25 impressions and zero clicks: zomato pos system, swiggy zomato, pos system with online ordering and swiggy pos integration. No landing page, country, device, position, date range or conversion dimensions were supplied.
The pinned product contains no verified native connector
A structured scan of 2,979 tracked readable files found no Swiggy product term and only four Zomato matches in presentation-icon assets. No non-presentation brand match or branded OpenAPI path was found.
Generic POS components do not equal integration
The published OpenAPI description contains 430 paths and a protected sale-create path. Its public request schema names items and sales_total only. The sale model has POS and restaurant fields but no reviewed external-order, aggregator or idempotency field.
Selected tests establish a security and call-path boundary only
Seventeen public-route and sales call-path tests passed. They cover guarded routes and named front-end calls, not platform onboarding, menu sync, webhooks, status callbacks, retry, settlement, support or live mapping.
Official platform approval is separate
Zomato's current official program describes onboarding, keys, configured webhooks, feature parity, testing, legal agreement, support and first live restaurant mapping. Selected official Swiggy sources establish restaurant-partner context, not a Posnic technical approval path.
Accept one platform-to-POS order lifecycle
Use synthetic data and a sandbox or platform-approved test environment. Preserve the same external and internal identity through every state and do not use a generic API endpoint as proof of approval.
| Control | Acceptance question | Evidence to retain | Current Posnic boundary |
|---|---|---|---|
| Platform authorization | Is the vendor and restaurant formally eligible and mapped for the exact platform and environment? | Agreement, platform contact, vendor and outlet IDs, sandbox access and mapping approval. | No Swiggy or Zomato vendor approval, agreement or live mapping was verified. |
| Credentials and webhooks | Are keys, headers, endpoint ownership, whitelisting and secret rotation approved? | Endpoint inventory, authentication design, secret owner, rotation record and platform configuration. | No branded webhook or credential contract was found in the pinned source. |
| Menu identity | Can items, categories, variants, add-ons, dietary tags and availability map without guesswork? | Stable IDs, source-of-truth decision, test menu, validation output and rollback record. | Generic item and sale components exist; no platform menu mapper was verified. |
| Price, tax and charges | Do item prices, discounts, packaging, delivery and tax values agree at every stage? | Known carts, expected totals, platform payloads, POS records and current tax-owner approval. | The published sale-create schema is too narrow to establish platform parity. |
| Order identity and retry | Does one external order map to one internal record across duplicate delivery, timeout and replay? | External and internal IDs, attempt IDs, idempotency rule, logs and one final outcome. | No reviewed external-order or idempotency field was found. |
| Order state | Do receive, validate, accept, reject, prepare, ready, pickup, delivery and timeout states remain consistent? | State map, timestamps, actor, reason, webhook and API evidence plus exception records. | No platform-specific state machine or callback contract was verified. |
| Kitchen handoff | Does the accepted order reach the correct preparation destination once with complete instructions? | Source order, mapped lines, KOT or display evidence, changes, cancellation and acknowledgement. | Bounded KOT components exist; no integrated aggregator-to-kitchen handoff was accepted. |
| Cancellation and support | Can customer, merchant and platform cancellations close the loop with a visible owner? | Reason mapping, status evidence, refund or exception owner and escalation transcript. | No branded cancellation or platform support integration was verified. |
| Settlement and privacy | Can order counts, charges, discounts, payment or settlement and permitted contact data be reconciled and protected? | Platform statement, POS report, variance log, access record, retention decision and accountable review. | No platform settlement import, privacy review or compliance result was accepted. |
| Outage, load and go-live | Can the integration stop safely, recover without loss or duplication and pass platform and business approval? | Load report, alert and escalation record, outage replay, clean reconciliation and signed first-live mapping. | No integrated load, outage, recovery or supervised live restaurant result exists. |
Practical workflow
Choose manual or integrated operation explicitly
A controlled manual transfer and an approved connector have different evidence. Name the current method on every order and do not describe retyping as synchronization.
Treat platform onboarding as a release dependency
Credentials and code are not enough. Keep current eligibility, agreement, platform configuration, feature-review and live-mapping evidence with the release decision.
Use stable identities before copying menu data
Map platform, outlet, menu, item, variant, add-on and order identities. Name the source of truth and the rollback path before enabling updates.
Model the complete order state machine
Document receive, validation, acceptance, rejection, timeout, preparation, ready, pickup, cancellation and completion. Unknown or conflicting states need a visible queue and owner.
Design retry around evidence
A timeout does not reveal whether the first request was applied. Preserve attempt identity and query the authoritative state before replaying a non-idempotent action.
Reconcile operations and money separately
Compare order lifecycle and kitchen output first, then compare discounts, charges, tax, payment or settlement and exceptions. One matching grand total can hide many mapping errors.
Keep trademark and affiliation claims accurate
Swiggy and Zomato names identify the platforms being evaluated. Their marks belong to their respective owners; Posnic does not claim affiliation, endorsement, certification or a native connector in this review.
An eight-step aggregator integration acceptance path
Complete the evidence in a platform-approved test environment before one supervised live restaurant mapping.
Define the release
Name the platform, vendor, restaurant, outlets, environment, transfer method, owner and stop rule.
Freeze authorization
Retain agreements, contacts, IDs, credentials ownership, endpoint configuration and whitelisting evidence.
Map the menu
Reconcile item, variant, add-on, tag, price, tax, charge, schedule and availability identities.
Trace known orders
Run accepted, rejected, unavailable, modified, cancelled, timed-out and duplicate-delivery samples.
Observe the kitchen
Compare every platform line and instruction with the single intended KOT or display result.
Remove dependencies
Fail platform access, webhook delivery, local service, kitchen output and network paths separately.
Reconcile and recover
Replay through the approved rule and reconcile lifecycle, exceptions, charges, settlement and reports.
Approve first live mapping
Complete platform review, load and support evidence, then obtain named business and technical approval.
Records needed before an integration claim
Platform and technical evidence
- Current vendor and restaurant eligibility, agreements, contacts and approved environments.
- Vendor, platform, outlet, menu, item and order identity maps with named sources of truth.
- Webhook and API endpoints, authentication headers, secret ownership, whitelisting and rotation records.
- Complete menu, order and outlet state contract for the exact platform version.
- Duplicate, timeout, replay, cancellation and malformed-payload behavior with retained logs.
- Load, availability, monitoring, alert, escalation and recovery evidence.
Restaurant and financial evidence
- Approved test menu with items, variants, add-ons, dietary tags, prices, taxes and charges.
- Known order set with expected KOT, preparation, ready, pickup and cancellation outcomes.
- Manual fallback that visibly prevents missing or duplicate preparation and sale records.
- Order, discount, charge, payment or settlement and exception reconciliation.
- Access, privacy, retention, food-operation and local-rule review by accountable owners.
- Platform review, first live mapping evidence and signed restaurant acceptance.
Setup sequence
- Use synthetic restaurant and customer data in a disposable or platform-approved test environment.
- Record the exact Posnic source commit and prove whether the proposed path is manual or integrated.
- Obtain current platform onboarding, agreement, credential, webhook and feature requirements directly from each platform.
- Create stable menu, item, variant, add-on, outlet and order identities before sending or receiving data.
- Build known accepted, rejected, timed-out, unavailable, modified, cancelled and duplicate-order samples.
- Trace each sample through platform state, Posnic state, kitchen output and final exception or completion evidence.
- Remove one dependency at a time and preserve visible state, retry decision and final duplicate-free result.
- Compare orders, item totals, discounts, charges, tax, settlement and reports against the fixed sample.
- Complete platform-required testing, architecture, load, support and escalation records.
- Approve one supervised live restaurant mapping before describing the connector as available.
What each person sees
Order-entry staff
Need a visible source and order identity, mapped items and instructions, current state and an exception queue that does not invite blind re-entry.
Kitchen staff
Need one complete preparation instruction and a controlled path for additions, cancellations, duplicates and unavailable items.
Supervisor
Needs rejected, timed-out, duplicated, cancelled and mismatched orders with reason, owner and resolution evidence.
Technical owner
Needs current platform contracts, credentials, webhook health, logs, alerts, load results, replay controls and escalation routes.
Owner or accountant
Needs platform orders, Posnic records, discounts, charges, settlement, cancellations and reports to reconcile to the fixed sample.
Mistakes to avoid
Avoid these during rollout
- Calling a generic POS API a Swiggy or Zomato integration.
- Claiming platform approval without current written vendor and live-mapping evidence.
- Using names rather than stable identities for items, variants, add-ons, outlets or orders.
- Blindly retrying a timed-out request without knowing whether the first action was applied.
- Creating a second manual order when an uncertain platform order may already exist.
- Sending an order to kitchen before required validation or losing later cancellation state.
- Checking only order totals while ignoring discounts, charges, tax, settlement and exceptions.
- Failing to preserve webhook, API, alert and operator evidence for incidents.
- Publishing affiliation, endorsement, certification or local-customer claims without evidence.
Run the blank 24-control delivery-aggregator acceptance record
Record the exact platform, restaurant, identities, menu, state machine, credentials, failures, reconciliation and approval. Observation and decision fields stay blank until the proposed workflow is exercised.
Primary sources used
Pinned Posnic source tree
Exact source boundary for the 2,979-file brand and connector scan.
Published Posnic OpenAPI description
Pinned 430-path contract used to inspect branded routes, security and the public sale-create schema.
Pinned Posnic sales routes
Source showing route protection and the generic sale-create path.
Pinned Posnic sale model
Source reviewed for restaurant fields and absent external-order, aggregator and idempotency fields.
Selected Posnic tests
Public-route and sales call-path tests used for the 17-test boundary; they are not platform integration tests.
Zomato POS integration overview
Official menu, order, outlet, API and webhook overview; it does not establish Posnic participation.
Zomato integration prerequisites
Official current eligibility, feature, support and availability prerequisites; confirm them directly before planning.
Zomato critical feature list
Official menu, order and outlet feature list used to structure acceptance controls.
Zomato pre-integration guide
Official onboarding, webhook, API-key, NDA and whitelisting sequence.
Zomato order management
Official order endpoints and webhooks for live states, cancellations, complaints and masked contact details.
Zomato menu management
Official menu and stock API surface used to frame item and availability controls.
Zomato post-integration guide
Official product review, architecture, load, agreement, support and first-live mapping expectations.
Swiggy food-delivery business
Official description of the marketplace and restaurant-partner fulfilment context; it is not a Posnic integration contract.
Swiggy restaurant-partner guide
Official partner-onboarding context selected for this review; obtain current technical integration requirements directly from Swiggy.
RFC 9110 HTTP semantics
Primary retry boundary for non-idempotent requests after partial or uncertain application.
OWASP API Security Top 10
Primary API-security review framework; it is not a Posnic security certification.
NIST SP 800-34 Rev. 1
Primary contingency-planning model used to structure dependency, fallback, recovery and test records.
Questions
Does Posnic v1.3.0 include a native Swiggy or Zomato connector?
No verified native connector was found. The only four Zomato source matches were presentation-icon assets; no Swiggy product match, branded OpenAPI path or connector model field was found.
Does the Posnic REST API make custom integration ready?
No. A protected generic sale endpoint is one component, not a platform contract. Menu synchronization, webhooks, state transitions, external identity, retry, support, approval and live mapping remain unverified.
What does Zomato currently require from POS vendors?
Its official documentation describes onboarding, API keys, configured webhooks, whitelisting, critical feature parity, testing, architecture and load evidence, legal agreement, support and first live restaurant mapping. Verify the current requirements directly with Zomato.
What does this review prove about Swiggy integration?
Only that selected official Swiggy sources describe its food-delivery marketplace and restaurant-partner onboarding context. They do not prove a technical Posnic connector or platform approval path.
Can a restaurant start with manual transfer?
A controlled manual workflow can be evaluated, but every order needs a source identity, line and charge verification, kitchen evidence, exception handling and reconciliation. It must not be described as synchronization.
How should duplicate or timed-out orders be handled?
Preserve the external order and attempt identities, inspect the authoritative platform and POS states, and replay only through an approved rule that proves one final outcome.
When can Posnic publish that an integration is available?
After the exact connector passes all 24 controls, platform-required review and load evidence, failure and recovery tests, settlement reconciliation and a supervised live restaurant mapping with written approval.
Where Posnic fits
Posnic Community Edition v1.3.0 provides bounded generic sale, restaurant and KOT components, and 17 selected route and sales call-path tests passed. It does not have a verified native Swiggy or Zomato connector, branded webhook contract, platform approval, external-order idempotency control, load result, live restaurant mapping or accepted integrated order. Complete the blank 24-control record and obtain current platform approval before rollout.