Delivery destinations

A destination is where a finished job’s items are delivered, on top of the copy the platform already stores. Add one under Settings → Deliver a copy elsewhere. Destinations are optional. Your items are readable in the dashboard and kept for your plan’s retention period either way. Add one when you want the data to land somewhere of your own - and when you want it to outlive that retention window.

​

Why it runs outside the container

Delivery happens on our side, never from inside the spider’s container. That is not a detail of implementation, it is the point:

• your database credentials never sit in an environment that also runs third-party code - your dependencies, and whatever they pulled in;
• delivery works regardless of what the spider does. A run with its own pipelines switched off writes nothing anywhere, and its items still arrive at your destination.

Credentials are stored encrypted and are never shown back. The connection string appears in the dashboard masked.

​

MongoDB

The form asks for four things: Items are inserted in batches, unordered, so one rejected document does not stop the rest. Every document gets four fields attached, because a collection filled by several jobs is impossible to reason about without them:

​

When delivery happens

Once per job, when the job reaches a final state and has items in storage. A job that scraped nothing has nothing to deliver, and nothing is sent. Every enabled destination on the project receives the same items - add two and both get a copy.

​

Reading the result

Two places say what happened:

• the destination itself shows last delivery - ok, or the error - and when;
• the job row shows the outcome per destination in its Delivered column: 1 240 → mydb.items, or the failure.

​

Turning one off

A destination can be removed at any time. Nothing already delivered is affected, and the platform’s own copy of the items is untouched.

​

Next steps