logo LinkShift.app
Sign inStart now
logo LinkShift.app
Go to App
LinkShift docs
OpenAPI-driven API documentation
Start
Overview
API reference
Guides
LinkShift Public API Guide
Domains and Domain Groups API
Redirect Rules API
Link Maps API
Link Map Entries API
Redirect Tests API
Concepts
Link Maps: Purpose, Behavior, and Safety
API endpoints
GET List domain groups
 POST Create domain group
 GET Get domain group
 PUT Update domain group
 DELETE Delete domain group
GET List domains
 POST Create domain
 GET Get domain
 PUT Update domain
 DELETE Delete domain
GET List link map entries
 POST Create link map entry
 DELETE Delete multiple link map entries by IDs
 GET Get link map entry
 PUT Update link map entry
 DELETE Delete link map entry
 POST Import link map entries
 POST Roll back imported link map entries
GET List link maps
 POST Create link map
 GET Get link map
 PUT Update link map
 DELETE Delete link map
GET Get organization usage summary
GET List redirect rules
 POST Create redirect rule
 GET Get redirect rule
 PUT Update redirect rule
 DELETE Delete redirect rule
 GET Get top redirect rules analytics
 POST Simulate redirect rule matching
GET List redirect tests
 POST Create redirect test
 GET Get redirect test
 PUT Update redirect test
 DELETE Delete redirect test
LinkShift docs
Guide
API reference

Redirect Tests API

Redirect test model and CI-safe validation workflow.

Source: backend/docs/public-api/redirect-tests.md

Redirect Tests API

Redirect tests allow storing expected routing outcomes and validating behavior over time.

Base path: /api/v1/redirect-tests

Endpoints

  • GET /api/v1/redirect-tests
  • GET /api/v1/redirect-tests/:id
  • POST /api/v1/redirect-tests
  • PUT /api/v1/redirect-tests/:id
  • DELETE /api/v1/redirect-tests/:id

Test Model

Each stored test includes:

  • domainGroupId
  • pathWithQuery
  • requestData (method/protocol/headers/query/ip/userAgent)
  • expectedResult (matched, statusCode, target)

Typical CI Workflow

  1. Upsert redirect rules and/or link-map entries.
  2. Update test fixtures via /redirect-tests.
  3. Execute simulations via /redirect-rules/simulate to validate current behavior.
  4. Fail deployment if simulated output diverges from expected results.