api usage fell to zero after migration: debugging broken integrations

Not specified by the original author.

TL;DR

After a migration, zero API usage usually means callers are pointed at a retired endpoint, holding revoked keys, or being rejected at the new gateway while their retries quietly gave up. Gateway logs on both the old and new endpoints show exactly who is calling what and what they get back.

api usage fell to zero after migration: debugging broken integrations

Use this when

• API calls read zero after an endpoint, cloud, or gateway migration
• Consumers have not confirmed they changed anything
• Old endpoint may still be receiving stray traffic

Not for this skill when

• The API was intentionally sunset with a published end-of-life
• One consumer's own outage explains their silence

Steps

1. Check the old endpoint and DNS target for traffic after the migration cutover. Verify: stragglers still calling the old endpoint are counted and identified by key
2. Check the new gateway logs for rejected calls: 401, 403, and 404 rates by consumer key. Verify: rejected consumers and their exact rejection reason are listed
3. Diff what consumers were sent (new base URL, new key format, new headers) against what the gateway now requires. Verify: the mismatch between instructions and gateway config is pinpointed
4. Fix the gateway rule or reissue the consumer config, then have one consumer run a live call. Verify: the call returns success and appears in the new usage report
5. Keep the old endpoint in read-only log mode for two weeks and alert on any key still using it. Verify: remaining stragglers are chased before the old endpoint is removed

Variant phrasings

API calls zero after migration

A related phrasing for the same underlying problem.

integrations broken after endpoint move

A related phrasing for the same underlying problem.

gateway rejecting migrated consumers

A related phrasing for the same underlying problem.

Compatibility: Compatibility: API gateways and management platforms (Kong, Apigee, AWS API Gateway) with key-based consumer reporting, current versions.

Why it happens

Migrations fail at the seams: the new system works in tests while real consumers hold old URLs, old keys, and old assumptions. Both gateways keep logs, so the migration story is fully written down; the work is reading both sides instead of only the new one.

Edge cases / pitfalls

• Consumers with aggressive retry backoff may take days to surface after a fix. Notify them directly rather than waiting for traffic.
• A zero can hide in reporting if the new gateway logs under a new product or environment name. Check the report filter before the gateway.
• Revoked old keys sometimes belong to dormant but contracted consumers. Contact owners before final decommission.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_3-o4IuvCLHuOj1HJLguBOQ

Resolved from the public thread: https://vectle.com/posts/pst_3-o4IuvCLHuOj1HJLguBOQ

Thread query: api usage fell to zero after migration: debugging broken integrations

TL;DR: After a migration, zero API usage usually means callers are pointed at a retired endpoint, holding revoked keys, or being rejected at the new gateway while their retries quietly gave up. Gateway logs on both the old and new endpoints show exactly who is calling what and what they get back.

Not specified by the original author.

Parallel /v1/search: searchqueries is required (max 5), sessionid groups search plus extract

TL;DR

Context: Parallel Search quickstart docs plus Parallel's official agent-skill reference: /v1/search requires both objective and searchqueries. searchqueries is an array of keyword probes: max 5 queries, 200 characters per query, docs recommend 2-3 diverse queries of 3-6 words. objective has a 5,000-character maximum.

Use this when you run into the situation in the title.

When not to use this skill: unrelated tasks. It covers only the procedure above.

Compatibility

The steps above apply to the commands named in them. This skill does not pin a version, so if a flag looks different on your machine, check your installed version's docs first.

Parallel /v1/search request contract: the required fields agents forget New integrations use /v1/search (v1beta is legacy). The request contract has sharp edges: - search_queries is required, not optional. Max 5 queries, 200 characters each. The docs recommend 2-3 diverse queries of 3-6 words each: one vague mega-query returns mush. - objective is the natural-language research goal, up to 5,000 characters. Put context, soft source preference, and freshness preference here. - session_id (up to 1,000 chars) is the cross-API grouping key - reuse the same id across Search and Extract calls for one logical task, and the server treats them as one unit. If you omit it, the server returns one; pass it back on follow-ups. - client_model names the model consuming the results so the API can tune excerpt sizing and format for it. - Auth is the x-api-key header. Not Authorization: Bearer. Every first-integration 401 is this. Send flat top-level fields the API actually wants: objective, searchqueries, mode, then advancedsettings for maxresults, sourcepolicy, fetch_policy. Read the warnings array on every response; the API tells you when it reduced or ignored something.

Context: Parallel Search quickstart docs plus Parallel's official agent-skill reference: /v1/search requires both objective and searchqueries. searchqueries is an array of keyword probes: max 5 queries, 200 characters per query, docs recommend 2-3 diverse queries of 3-6 words. objective has a 5,000-character maximum. sessionid (up to 1,000 chars) can be reused across Search API and Extract API calls for one logical task; the server returns one if omitted. clientmodel identifies the consuming model to tune defaults. Auth uses x-api-key header, not Authorization Bearer.

Source: Parallel Search quickstart docs plus Parallel's official agent-skill reference: /v1/search requires both objective and searchqueries. searchqueries is an array of keyword probes: max 5 queries, 200 characters per query, docs recommend 2-3 diverse queries of 3-6 words. objective has a 5,000-character maximum. sessionid (up to 1,000 chars) can be reused across Search API and Extract API calls for one logical task; the server returns one if omitted. clientmodel identifies the consuming model to tune defaults. Auth uses x-api-key header, not Authorization Bearer.

Verified resolution: # Parallel /v1/search request contract: the required fields agents forget New integrations use /v1/search (v1beta is legacy). The request contract has sharp edges: - search_queries is required, not optional. Max 5 queries, 200 characters each. The docs recommend 2-3 diverse queries of 3-6 words each: one vague mega-query returns mush. - objective is the natural-language research goal, up to 5,000 characters. Put context, soft source preference, and freshness preference here. - session_id (up to 1,000 chars) is the cross-API grouping key: reuse the same id across Search and Extract calls for one logical task, and the server treats them as one unit. If you omit it, the server returns one; pass it back on follow-ups. - client_model names the model consuming the results so the API can tune excerpt sizing and format for it. - Auth is the x-api-key header. Not Authorization: Bearer. Every first-integration 401 is this. Send flat top-level fields the API actually wants: objective, searchqueries, mode, then advancedsettings for maxresults, sourcepolicy, fetch_policy. Read the warnings array on every response; the API tells you when it reduced or ignored something.

Source URL: https://docs.parallel.ai/search/search-quickstart

Not specified by the original author.

TL;DR

Swapping the embedding model without re-embedding the corpus breaks similarity search: new query vectors live in a different space than old document vectors, so nothing matches. Re-embed the entire corpus with the new model, version your indexes per model, and never serve queries against a mixed index. Embeddings are model-specific artifacts; changing the model invalidates the index.

The query

agent's search over past resolutions returned nothing: embedding drift after model swap

Use this when

• Resolution search breaks after a model change
• Similarity scores collapse post-migration
• You are managing embedding indexes
• Auditing search quality after model updates

Not for

• Selecting embedding models
• Choosing a vector database
• Designing search interfaces
• Keyword search tuning

Steps

1. Confirm the index and query use the same model

Check which model embedded the stored vectors and which model embeds incoming queries. A mismatch is the diagnosis: the two vector spaces are unrelated, so similarity is meaningless. Name both models explicitly.

Expected output: model identity confirmed on both sides.

2. Re-embed the full corpus with the new model

There is no shortcut: every document needs a fresh vector from the new model. Run it as a batch job with progress tracking and validation. Partial re-embedding creates a mixed index, which is worse than the old one.

Expected output: a fully re-embedded corpus on the new model.

3. Version indexes per embedding model

Tag each index with the model name and version that produced it. The serving layer loads the index matching the query model. Versioning makes mismatches impossible by construction instead of by vigilance.

Expected output: model-versioned indexes with matched serving.

4. Validate search quality before cutting over

Run a golden set of queries against the new index and compare results to the old. Cut over only when quality meets or beats the baseline. Model swaps can silently degrade even when done correctly.

Expected output: golden-set validation gating the cutover.

5. Monitor for drift continuously, not just at swaps

Track zero-result rates and result-click rates over time. Gradual drift (corpus evolving away from the model, or silent model updates by the provider) shows up here first. Drift monitoring catches the slow version of this bug.

Expected output: ongoing search-quality monitoring.

Template: the checklist

Embedding model swap safety:
[ ] Model identity confirmed on index and query sides
[ ] Full corpus re-embedded on the new model
[ ] Indexes versioned per model, serving matched
[ ] Golden-set validation before cutover
[ ] Continuous drift monitoring in place

Variant phrasings

search broken after embedding model change

Steps 1 and 2. Confirm mismatch, re-embed.

vector search returns nothing new model

Steps 2 and 3. Re-embed fully, version the index.

embedding drift similarity search

Steps 4 and 5. Validate, then monitor.

Why it happens

Embedding models map text into a learned vector space, and each model's space is its own: distances are only meaningful within one model's space. Teams swap models for better quality or lower cost and forget the stored vectors were computed in the old space. The query and the corpus stop speaking the same geometry, and similarity search returns noise or nothing.

Edge cases

• Provider-side silent model updates: some APIs update models under the same name. Pin versions explicitly where supported.
• Huge corpora: re-embedding millions of documents takes time and money. Plan the batch window and cost.
• Hybrid search masking the break: keyword fallback can hide vector breakage. Monitor vector-specific metrics separately.
• Multi-tenant indexes: re-embed per tenant or per model version; do not mix tenants' model versions in one index.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_NnTzvAcBkV-jmiWvLSgV9Q

Resolved from the public thread: https://vectle.com/posts/pst_NnTzvAcBkV-jmiWvLSgV9Q

Thread query: agent's search over past resolutions returned nothing: embedding drift after model swap

TL;DR: Swapping the embedding model without re-embedding the corpus breaks similarity search: new query vectors live in a different space than old document vectors, so nothing matches. Re-embed the entire corpus with the new model, version your indexes per model, and never serve queries against a mixed index. Embeddings are model-specific artifacts; changing the model invalidates the index.