do I need a separate endpoint for reranking?

Usually, yes — if you want a true reranking step, it’s common to expose it as a separate endpoint.

Why separate?

• Different input/output shape: retrieval returns candidates; reranking takes those candidates and reorders them.
• Different model behavior: rerankers often score query-document pairs, while retrieval embeds and searches.
• Easier orchestration: your app can first call search, then rerank the top N results.

Typical setup

1. /search or /retrieve
   Returns top-k candidate documents.
2. /rerank
   Accepts:
   • user query
   • candidate list
   • optional metadata Returns candidates sorted by relevance score.

When you might not need a separate endpoint

• If your backend can do retrieve + rerank internally in one request.
• If you’re using a managed API that already combines both steps.
• If reranking is just an optional post-processing step in the same service.

Rule of thumb

• Separate endpoint if reranking is a distinct service, model, or scaling concern.
• Single endpoint if you want a simpler API and can hide the rerank step behind the scenes.

If you want, I can sketch a simple API design for both options.