Skip to main content

Asynchronous Processing

We-Link utilizes an asynchronous processing model for the vast majority of API endpoints, such as sending messages or connection requests. This design is essential for both performance and account safety.

How It Works

When you trigger an action through our API, we do not make your system wait for the task to finish. Instead:

  1. We immediately acknowledge your request and provide a unique requestId
  2. Your application continues its workflow without interruption
  3. Our engine processes the operation in the background

Getting Results

Once the background operation is complete, you have two options to receive the results:

We push the final result directly to your configured webhook endpoint the moment the task is finished. This is the most efficient approach.

  • Webhook payload delivered to your endpoint
{
"status": "SUCCESS",
"requestId": "1234ab5678290....",
"result": { // result may vary according to the type of the endpoint
"connected": true,
"profile_id": "ACoABC1d2f..."
},
"hash": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...." // hash for verification
}

Option 2: Polling

If you prefer to monitor progress yourself, use the request_id to query our status endpoint:

POST /api/v1/get_response

{
"request_id": "1234ab5678290...."
}

Why Asynchronous?

LinkedIn operations through We-Link are long-running tasks by design. To keep your account safe, our processing engine incorporates human-like delays, randomized timing, and sequential execution between actions. A single request — such as sending a connection request — may take anywhere from a few seconds to several minutes to complete, depending on the current queue and safety pacing.

Making your application wait synchronously for each operation to finish would:

  • Block your app unnecessarily — Your system would be idle, waiting on a response that could take minutes
  • Limit throughput — You wouldn't be able to queue additional actions while waiting for one to complete
  • Create tight coupling — Network timeouts or transient delays would force complex retry logic on your side

By returning a requestId immediately and processing in the background, We-Link lets your application move on instantly while we handle the heavy lifting — executing each action with the appropriate safety delays and delivering the result to you when it's ready.

Queue Timeout

Requests that remain queued for too long are automatically marked as failed with the status QUEUE_TIMEOUT_THRESHOLD_EXCEEDED. This prevents requests from being stuck indefinitely and ensures stable, fair processing of newer requests. If you receive this error, re-submit the request.

Scheduling Requests

You can schedule any API request to be executed at a later time by including the optional scheduled parameter in the request body.

How It Works

  1. Add a scheduled field with a date-time string in ISO 8601 format (YYYY-MM-DDTHH:mm:ss.sssZ)
  2. The scheduled time must be at least 2 hours later than the current time — requests that don't meet this minimum will be rejected
  3. The request is queued and automatically executed at the specified time
  4. Results are delivered via your webhook just like any other async request

Example

{
"accountId": "1234ab5678290....",
"profile_id": "ACoABC1d2f...",
"message": "Hi Jane, great connecting with you!",
"scheduled": "2025-09-22T18:30:00.000Z"
}
caution

The scheduled value must be in UTC. Ensure proper time zone awareness to avoid executing requests at unintended times.