Authoritative Tutorial on the Do1 Qiqiao Customer Information Query API Field Handbook

What This API Solves

In real CRM-plus-low-code integration scenarios, customer master data is usually scattered across multiple systems. We often need to read customer profiles out of a Do1 Qiqiao (Do1QQ) form application so that upstream systems such as Xiaoman OKKICRM can perform deduplication, while downstream sync strategies gain a reliable source of truth about whether a target record already exists. This API is a typical "query-only" data source strategy: it does not write to any target — it only pulls customer master data back to the platform in a stable way, so that subsequent write strategies can compare and locate records by business code.

API Capability Overview

• API form: A form-data query API at the path /plus/cgi-bin/open/applications/{applicationId}/forms/{formModelId}.
• Authentication: On the Qeasy platform, calls are made through the encapsulated adapter with authentication headers; developers do not need to manage tokens manually, but the application id and form model id must be maintained in the connector.
• Request parameters: applicationId, formModelId (required), startTime and endTime for the time-range increment, orderField (default createDate), isAsc (default false), page, and pageSize (default 1 / 50).
• Response structure: data.list is the actual list payload. The platform parses it automatically through autoFillResponse: true, and otherResponse.statusKey points to data.list.
• Incremental & pagination mode: Records are pulled in descending order of createDate with pagination, and are commonly scheduled with a high-frequency small-window increment such as the crontab 1-59/4 8-23 * * *.

Typical Field Mapping

How to Configure It on Qeasy

On the Qeasy Data Integration Platform, this API is usually onboarded as a "query-only data source strategy." Several configuration actions matter:

1. Connector selection: Use the built-in Do1 Qiqiao adapter, fill in the application id (applicationId) and the customer form model id (formModelId); the adapter handles authentication uniformly.
2. Response mapping: Because the platform enables autoFillResponse: true, the Qeasy field mapper automatically expands the list from data.list — no need to write custom JS.
3. Field mapper: Map 公司 to the universal concept customer_name, 用于外键关联 to customer_code, and extend.id to form_instance_id so that downstream strategies can reuse them.
4. Target configuration: Explicitly set the Target to "Write Null Operation," meaning the strategy reads only; results are written to the platform's intermediate table, ready for downstream strategies such as "Xiaoman Customer => Do1 Customer ok" to look up by 用于外键关联 via _mongoQuery.
5. Scheduling: The common pattern is a high-frequency small-window schedule like 1-59/4 8-23 * * *, paired with the {{LAST_SYNC_TIME}} incremental cursor, to keep data fresh during business hours.

Cross-Strategy Practical Points

1. Business code is the soul of deduplication: The 用于外键关联 field must be stable and unique; all cross-system customer comparisons should prefer it over fuzzy name matching.
2. Always go deep for extend.id: The update API needs the 32-character form-instance id. It is easy to forget the .extend.id path, which results in 404s on update.
3. Use milliseconds for the incremental cursor: Do1 Qiqiao's time-range parameter is in milliseconds; the 000 suffix in the template must not be omitted, otherwise you will pull full history.
4. Descending pagination is more reliable: Default isAsc=false and sort by createDate descending handles concurrent writes better and avoids missing boundary records.
5. Explicitly declare null-write for query-only strategies: Mark the Target as "Write Null Operation" so the scheduler correctly identifies the strategy type and avoids unintended writes.
6. Let the platform parse the response: Enabling autoFillResponse and letting the Qeasy field mapper expand data.list eliminates a lot of custom parsing scripts.

Pitfall Recap

1. Wrong timestamp unit: Pasting a second-level timestamp into startTime/endTime returns an empty window or pulls the entire history. The safe approach is to always append 000 in the template to convert to milliseconds.
2. Wrong primary-key path: Mistaking content.id for the form-instance primary key, while the real id lives at content.extend.id. Update calls then return "record not found."
3. Same-name overwrite risk: Deduplicating by company name alone causes different entities with the same name to overwrite one another. Always lock the record by 用于外键关联 first, then decide insert vs update.
4. Incremental mixed with full sync: Failing to use the {{LAST_SYNC_TIME}} template causes a full pull on every run, which triggers API rate limits. Backfill the historical cursor before switching to incremental mode.
5. Misconfigured Target: A query-only strategy accidentally gets a write target configured, triggering unnecessary downstream calls. The Target should be explicitly set to "Write Null Operation."

When to Use It

This query API is the right choice when your business logic needs a "query-before-write" pattern — using the business code to determine whether a customer record already exists on the target side, and then deciding whether to insert or update. If your flow is a simple one-way pull without comparison, or if the target system already provides upsert semantics, you can skip this extra query-only strategy and go straight to direct sync.