LINGLI / Developer guides
What to check before integrating a social media data API
Before making batch requests, review data scope, authentication, pagination, business outcomes, retries, costs and retention rules to build a verifiable API integration process.
Lingli Data · Updated 9 October 2026
Receiving JSON from one request verifies only part of an integration. Before adding a social media data API to a business system, understand its fields, pagination, error handling, billing and data-use boundaries.
Use the following checks to prepare an integration. For Lingli-specific requirements, refer to the current console documentation. These general methods do not imply that every API offers the same parameters or response structure.
Identify the data you actually need
List the fields your business needs and the decisions they support. Researching public topics, displaying content lists and analyzing engagement often require different scopes.
Record the platform, query conditions, time range and content visibility requirements. Confirm the basis for using public or authorized data and the limits on retention, display and export. A field being returned does not mean it can be used for every purpose.
Keep authentication on the server
Lingli’s public examples use the X-API-Key header and read the key from a server-side environment variable. Browser pages must not hold real API keys.
For troubleshooting logs, retain only the necessary method, API name, time and sanitized error category. Full request headers, responses containing sensitive information and real keys must not appear in public logs.
Check HTTP status and business outcomes separately
HTTP status describes the result at the protocol level, but the response’s business meaning must still be interpreted using the documentation. Do not treat any non-empty JSON as business success or an empty list as a system failure.
Define separate handling for success, empty results, format changes and failures. Distinguish a missing field from a numeric zero; a broad empty-value check must not discard valid zero values.
Confirm pagination for each API
Some services use page numbers, while others use offsets or continuation tokens. Similar products may use entirely different parameters. Apify’s public API documentation distinguishes general pagination from endpoint-specific exceptions, illustrating why you must read each endpoint’s documentation instead of copying parameters.
When integrating Lingli, use the current API documentation to confirm whether pagination is available, what the next request requires and when to stop. The website’s Facebook example does not specify a complete pagination protocol, so it cannot establish support for a particular continuation field.
Review pagination design for stopping at the required scope, avoiding duplicate processing, detecting repeated results and recording progress. These are application-side design goals; implementation depends on the API contract and business requirements.
Consider cost and duplicate processing before retrying
A network timeout may not reveal whether the remote server has already processed a request. Automatic retries can incur additional charges and duplicate business writes.
Check the permitted retry rules and billing conditions first. Set explicit attempt and time limits. For steps that may duplicate processing, use suitable deduplication or manual confirmation. Do not ignore the cause of repeated failures just because an error temporarily disappears.
Run an integration acceptance test with a defined scope
| Check | Evidence to retain |
|---|---|
| Request construction | Documentation version, method, required parameters and sanitized request records |
| Authentication | Server configuration location and checks confirming keys are not exposed in the frontend |
| Response parsing | Fields, empty results and error handling verified against the documentation |
| Pagination | Stop conditions, duplicate detection and progress records |
| Billing | Confirmed rules and request records for this task |
| Business integration | Data sources, permitted use, retention periods and access roles |
Clearly label acceptance samples as real requests or simulated data. Simulated samples can test code paths but cannot establish live availability, complete data coverage or correct billing.
Then decide whether to expand the task
After small-scale validation, evaluate update intervals, costs and failure handling against the actual workload. State the test inputs, environment and statistical method for any conclusion about scale, speed or success rates.
Before integrating Lingli, check current API scope and pricing in the console, then prepare validation steps for your own business requirements.
View the Lingli API marketplace
References
Apify API documentation: pagination and errors. This reference covers general integration methods; Lingli parameters are governed by Lingli’s own documentation.