Technical design for API development and integration
Agree business objects, inputs, outputs and failure handling before choosing architecture. The content-system examples below illustrate mappings, queues, callbacks and handover.
Architecture, code, accounts and monitoring records are design examples. Numbers and responses are illustrative data, not client deliveries or measured performance. Scope and capacity require project implementation and acceptance.
Four inputs for an API design
| Design area | Agree before implementation | Acceptance evidence |
|---|---|---|
| Contracts and fields | Objects, inputs, outputs, pagination, nulls, versions and sync direction | Redacted samples, field mappings and API specifications |
| Accounts and access | Ownership, scopes, isolation, revocation and expiry | Least-privilege and cross-client access cases |
| State and recovery | Timeouts, duplicates, out-of-order callbacks, operator handling and reconciliation | Failure replays and business outcome records |
| Handover and maintenance | Source, environment, logs, alerts, backups and external dependencies | Delivery checklist and deployment rehearsal |
Choose modules from API development services and carry these inputs into the acceptance process before estimating effort. Adapt the illustrative content-system architecture below to the agreed workflow.
Five tables carry most of the system
| Table | Holds | Key rule |
|---|---|---|
| accounts | Platform account, owner, authorization state | One row per account; credentials encrypted |
| projects | Client or brand scope, permissions | Every content row belongs to a project |
| contents | Draft, platform versions, media | Immutable versions; edits create a new one |
| posts | Publish job, platform id, status | Unique idempotency key per target |
| metrics | Indexing, citations, engagement | Raw records per run, not just totals |
One worker per account
Publishing never runs inline in a request. Jobs are queued, rate-limited per account, and retried with backoff. Idempotency keys make retries safe.
def publish(job):
account = accounts.get(job.account_id)
if not account.can_publish():
queue.delay(job, reason="authorization")
return
limiter.wait(account.platform, account.id)
platform = adapters[account.platform]
payload = platform.map(job.content) # fields per platform
result = platform.publish(account, payload) # idempotent by key
if result.retryable:
queue.retry(job, backoff="exponential")
else:
store.finish(job, result)POST /v1/posts
{
"account_id": "acc_1024",
"platform": "xiaohongshu",
"type": "note",
"title": "Autumn pour-over guide",
"media": ["media_88", "media_89"],
"schedule_at": "2026-10-24T10:00:00+08:00",
"idempotency_key": "post_20261024_001"
}Collect what you can verify
Indexing, on-platform search and AI citations are separate sources. Each record carries its source and timestamp, missing data is marked as missing, and reports keep the raw rows behind every number.
Authorization without passwords
Confirm the platform-approved authorization route, granted permissions and revocation process. Design encrypted credential storage and client isolation; do not substitute password collection or simulated login for permission.
Self-hosted or hybrid
Select hosting, data storage and operational dependencies from the agreed workload and client environment. Define source handover, deployment instructions, alerts, backup recovery and maintenance responsibilities together.
Engineering questions
Why not use an existing open-source publishing system?
Most open-source options cover calling one platform API. Account matrices, rate limits, retries, review callbacks and multi-client isolation still have to be built. We start from those modules, so the delivery is a working system rather than an SDK demo.
Is monitoring fragile?
Yes. AI answer pages change structure often, so collection has two layers: stable platform or public endpoints first, browser automation as a fallback, with each source degrading independently. Missing data is shown as missing rather than filled with zero.
How much publishing volume can the system handle?
Throughput targets depend on account scale, content types, platform rate limits and deployment resources. Queues can be partitioned by account. Actual capacity requires agreed load testing; this page provides no untested QPS figures.
Can we use only the API layer without the admin UI?
Yes. Delivery can be an API service plus SDK connected to your existing backend, or include a minimal admin interface.
Share your APIs and business samples
Agree fields, access, failure handling and handover before selecting a technical design.