Track U.S. land border crossing volumes by port

The problem

U.S. Customs and Border Protection counts inbound crossings at every land port of entry on the Canadian and Mexican borders, and the Bureau of Transportation Statistics publishes the counts monthly as the Border Crossing Entry Data dataset. If you follow freight or traveller volumes at particular ports, the work is noticing when a new month lands and whether earlier counts were revised.

This guide monitors the dataset as one record per port, month and measure, keyed by an identifier built from the three, so each run reports new months and revised counts.

What the source contains

U.S. land border crossing entries by port, monthly · Bureau of Transportation Statistics (U.S. Department of Transportation)

Monthly counts of inbound trucks, trains, buses, personal vehicles, passengers and pedestrians at each U.S.-Canada and U.S.-Mexico land port of entry, the 1,000 most recent port, month and measure rows (about two months).

10 typed fields · 1,000 records in SourceFinch's latest run on October 12, 2026 · publisher updates: monthly · full source page

What a change means

• A new id: a count for a port, month and measure that was not in the previous run, usually a new month. measure says what was counted and value how many.
• A change to value on an id you already have: a revised count.
• To follow only your ports, filter on border, state or port_code in an export or in the system that receives your webhook.

Set it up in the console

1. Open the Verified recipe. Open the U.S. land border crossing entries by port, monthly recipe in the console. It keeps the reviewed URL, fields and record key (id), and shows the latest captured sample. Open in the console
2. Create the monitor. Name the monitor, keep the daily schedule or pick another (the console shows the monthly run cost), confirm that you have the right to monitor the source, and choose Create monitor.
3. Run the baseline. The first run is the baseline: every record is new. From the second run on, the monitor reports what was added, changed or removed, field by field, with the evidence behind each value.
4. Choose how you hear about changes. In Alerts, choose immediate change emails or a daily or weekly digest; each monitor can override that on its own page. For your own systems, add a signed webhook in Destinations. Alerts and team
5. Export the counts. Export the monitor as CSV, JSON or XLSX to chart a port's volumes; each row keeps port_name, month, measure and value.

The same through the REST API, CLI or MCP

Every surface creates the same monitor from the same Verified recipe. You confirm you have the right to collect the source (rights: true).

U.S. land border crossing entries by port, monthly

# the Verified entry (fields, recipe, sample, terms) as JSON
curl https://sourcefinch.com/v1/catalog/bts-border-crossing-entries -H "Authorization: Bearer $SOURCEFINCH_API_KEY"

# create the monitor from source.json (below)
curl -X POST https://sourcefinch.com/v1/sources \
  -H "Authorization: Bearer $SOURCEFINCH_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: $(uuidgen)" \
  -d @source.json

# then run it now (later runs follow the schedule)
curl -X POST https://sourcefinch.com/v1/sources/$SOURCE_ID/runs \
  -H "Authorization: Bearer $SOURCEFINCH_API_KEY" \
  -H "Idempotency-Key: $(uuidgen)"

sourcefinch login
sourcefinch catalog get bts-border-crossing-entries --source-json > source.json
sourcefinch sources create --file source.json
sourcefinch runs create $SOURCE_ID --wait
sourcefinch records $SOURCE_ID

claude mcp add --transport http sourcefinch https://sourcefinch.com/mcp

# then ask your agent:
"Use SourceFinch to monitor U.S. land border crossing entries by port, monthly: get_catalog_source bts-border-crossing-entries,
then create_source with its create_source_args (dry run first), then run_source."

{
  "name": "U.S. land border crossing entries by port, monthly",
  "url": "https://data.bts.gov/resource/keg4-3bc2.json?$select=port_code%7C%7C%27/%27%7C%7Cdate_extract_y(date)%7C%7C%27-%27%7C%7Cdate_extract_m(date)%7C%7C%27/%27%7C%7Cmeasure%20as%20id,port_name,state,port_code,border,date,measure,value,latitude,longitude&$order=date%20DESC,port_code,measure&$limit=1000",
  "recipe": {
    "mode": "http",
    "format": "json",
    "items": "[*]",
    "fields": {
      "id": "id",
      "month": "date",
      "state": "state",
      "value": "value",
      "border": "border",
      "measure": "measure",
      "latitude": "latitude",
      "longitude": "longitude",
      "port_code": "port_code",
      "port_name": "port_name"
    },
    "required": [
      "id",
      "port_code",
      "month",
      "measure"
    ],
    "types": {
      "month": "date",
      "value": "integer",
      "latitude": "number",
      "longitude": "number"
    }
  },
  "key_field": "id",
  "schedule": "daily",
  "rights": true,
  "catalog": {
    "slug": "bts-border-crossing-entries",
    "version_id": "b67743da-bbfb-418b-9a3a-a8cc7ff206a4"
  }
}

Alerts and evidence

A new month adds a record for every port and measure at once, so a weekly digest or a webhook into your own table suits this monitor better than an email per change.

Every run keeps the publisher's exact response with its SHA-256 hash and a signed manifest, and every value points back to where it was read. How that works is in the docs:

• Review changes and receipts
• Alerts: change emails and digests
• Evidence and export: what a run keeps, bundles, CSV/JSON/XLSX
• Checking an evidence bundle offline
• Verifying signed webhooks
• Rights and acceptable use

Limitations

• Each run reads the 1,000 most recent port, month and measure rows, about two months. A row leaving that window is not a deletion.
• Only inbound crossings are counted; CBP does not count outbound crossings.
• The counts are aggregates of vehicles and people and contain no personal data.

Usage rights, terms posture and reliability for each source are on its source page. They are our documented understanding of each publisher's stated terms, not legal advice.

Related