Skip to main content

Configure a delivery service

This page is a safety boundary for the source-defined delivery-service detail panel. It is not an executable setup procedure. Configuration requires provider and project state that was deliberately not accessed for this documentation pass.

Configuration changes are live

Opening the parent page performs authenticated reads. The detail panel can expose provider configuration and operational associations, and its controls can write service enablement, driver-group settings, linked businesses, payment methods, schedules, and delivery-zone state. Do not open or interact with it for documentation verification.

Before you start

  • Use a secret-free synthetic project dedicated to integration testing.
  • Intercept setup navigation and deny all provider egress, callbacks, jobs, and live API writes.
  • Supply synthetic delivery-company, plugin, driver-group, business, payment-method, schedule, and delivery-zone records.
  • Prove that no real credential, account, store, order, or provider endpoint is reachable before loading the route.

Without that fixture and proof, configuration remains blocked and excluded. A branch, feature flag, local source checkout, or CI result is not a runtime or provider receipt.

Open the service detail panel

Current source attempts to open details only for a returned delivery company with both a plugin identifier and a linked driver-group identifier, then reads that group. This sequence is descriptive only and must not be performed against a live project for documentation.

Depending on the provider configuration, the panel can expose these tabs:

  • General — provider-defined setup fields.
  • Businesses — business associations.
  • Schedule — availability schedule.
  • Payment methods — payment methods allowed for the delivery group.
  • Delivery Zones — enabled delivery zones for the linked group.

The latter tabs are conditional on the client considering plugin configuration complete; Payment methods and Delivery Zones additionally require a returned group identifier. These conditions do not establish provider readiness or deployed behavior.

Some plugin records can expose Start Setup or an in-Dashboard setup modal. Current source can construct a credential-bearing external setup destination from session and project context.

Do not copy or capture the setup URL

Do not open, copy, inspect, log, capture, or reconstruct the setup destination. It is excluded from this documentation workflow until an approved synthetic fixture intercepts navigation and proves zero provider egress.

Provider fields are derived from configuration records read by plugin key. Do not enter or change values during review: in current client source, changes in the General form can trigger a driver-group update through a reactive effect rather than waiting for an explicit Save action.

Write and effect classes

Source defines separate writes for delivery-company enablement and driver-group configuration. Driver-group updates can include business associations, allowed payment methods, schedule, and logistics values. Delivery-zone Save iterates changed zones and sends individual update requests, so partial completion is possible.

Plugin installation, setup navigation, configuration writes, callbacks, provider activation, connection tests, dispatch behavior, and successful effects are all excluded here. Re-entry requires the exact synthetic, secret-free, deny-egress fixture described above and immutable receipts for every admitted effect.

Troubleshooting

Why do I see only General?

Current source exposes additional tabs only after its configuration-state check and, for two tabs, a group identifier. No provider-specific readiness is inferred.

Why did a save fail?

No save was attempted. Source contracts include authorization, validation, record-limit, relationship, and plugin-hook boundaries; a future approved test must capture the exact rejected or accepted response without provider egress.


Related guides: Delivery services overview · Delivery overview