Tripadvisor is built for research. Your product needs a decision.

InBetween turns restaurants, bars, and cafés into structured answers for apps: preference matching and multi-person search without sending users to a review destination.

Get Started
api.inbe.us/v1/search200 OK
POST
{
"locations": [
{ "lat": 51.5072, "lon": -0.1276, "weight": 30 },
{ "lat": 51.5154, "lon": -0.1419, "weight": 40 },
{ "lat": 51.5034, "lon": -0.1195, "weight": 30 }
],
"mode": {
"mode": "POINT"
"maxDistance": 200
},
"preferences": {
"openingConditions": {
"state": "ANY"
"atTime": "2026-08-15T17:53:51.178Z"
},
"goodFor": ["family", "coffee", "date"]
"catersFilters": ["vegetarian", "glutenFree", "vegan"]
"establishmentFilters": ["restaurant"]
}
}

For teams that outgrew review-site handoffs

Reviews help people browse. Products need to decide.

Tripadvisor solves a real problem: help travellers research places through reviews, rankings, and guides. That model is excellent for open-ended discovery on a destination site. It is a poor fit when the intent already lives inside another product.

When a messaging app, travel concierge, or AI assistant pushes someone to a review site, the product loses control of the moment. The user is left comparing screenshots and opinions that were never structured for the constraints of their plan.

InBetween is built for that moment instead. We maintain detailed venue profiles and match them to people, preferences, and locations in one request, so your product can return a shortlist rather than a research assignment.

What breaks today

  • Review destinations are optimised for browsing, not for multi-person product constraints.
  • Handoffs to Tripadvisor break the journey and the brand continuity.
  • Teams end up scraping sentiment from text because the structured signals they need are missing.

What you can ship

  • Turn 'where should we go?' into an in-product answer.
  • Filter on structured hospitality attributes instead of review text.
  • Keep engagement inside your app at the decisive moment.

How it works for you

  1. 01

    Query structured venue attributes

    Atmosphere, dietary coverage, price, and occasion fit are fields you can filter on — not buried in review prose.

  2. 02

    Resolve the plan, not the browse

    Multiple people and locations go into one call. We return options that work for the group, ready to render.

  3. 03

    Stay the product of record

    Users decide where to go without leaving your experience for a review destination.

How we compare to other Places APIs

We find the right place for everyone, not just a pin on a map.

Traditional place APIs are designed to return place records. InBe is designed to resolve real decisions: where should these people meet, given everyone's needs, preferences and the experience they want?

Find and rank restaurants, bars and cafés around the people, preferences and experience that matter. From dietary and accessibility requirements to vibe, menu items and much more.

  • Preferences at the core

    Search across dietary needs, accessibility, atmosphere, vibe, menu items and other meaningful preferences, not just category.

  • Built for more than one person

    Bring multiple people's locations, and requirements, into one search and rank places for the group. No manual comparison or lowest-common-denominator filtering.

  • Optimised for an experience

    InBe helps products answer 'Where should we go?' rather than merely returning nearby records or pins.

Illustrative scenario: When preferences, access and vibe all matter

Four people are meeting for dinner. One is vegan, one needs step-free access, one wants somewhere quiet enough to talk and another needs a stiff drink. All within a practical journey for the group.

Conventional Places APIs

Conventional Places API

In progress

£0.00/1k · 250ms

  1. 250ms

    Identify the best location for the group

  2. 30ms

    Search by category at that location and receive 20 candidates

  3. 115ms · £0.005

    Receive 20 locations in that category

  4. 110ms · £0.01

    Request additional place details

  5. 80ms

    Identify relevant places

  6. 1800ms · £0.10

    Source missing menu, dietary or accessibility data

  7. 80ms

    Build custom preference and group-ranking logic

  8. 100ms

    Present options and ask users to compare them

More requests, more integration work and more decisions left to the user.

InBe

Building with InBe

In progress

£0.00/1k · 30ms

  1. 30ms

    Send the participants locations and preferences

  2. 175ms · £0.005

    Receive a ranked shortlist of 20 suitable places

  3. 110ms · £0.001

    Enrich only the places the user wants to explore

Fewer unnecessary calls, less custom logic and a faster route to a confident decision.

Conventional outcome

20 locations in the area

Nearby category matches. Preference fit and ranking still sit with you.

Total time
2,565ms

Sum of illustrative step latencies for one cycle

Cost per 1k
£115.00/1k

Illustrative list-price usage across 1,000 runs

Steps to a shortlist
8

Integration and request steps in the conventional path

Decision state
User still compares

Shortlist quality depends on filters you build and data you chase.

InBe outcome

20 perfect locations

Ranked shortlist around the group’s preferences, access needs and vibe.

Total time
315ms

Sum of illustrative step latencies for one cycle

Cost per 1k
£6.00/1k

Illustrative list-price usage across 1,000 runs

Steps to a shortlist
3

Core API actions in the InBe path

Decision state
Decision-ready shortlist

Enrich only the places people actually want to open.

About 8.1× faster and 19.2× lower cost per 1k runs in this scenario.

Capability at a glance

How a general-purpose Places API alternative compares with InBe's preference-aware restaurant recommendation API.

Strong fit / includedVaries by providerOften needs extra work

Find nearby places

Conventional Places APIs
Core focus
InBe
Included

Search around advanced preferences

Conventional Places APIs
Often requires extra data
InBe
Built in

Reconcile multiple people's needs

Conventional Places APIs
Usually requires custom logic
InBe
Designed for this

Rank places for a shared experience

Conventional Places APIs
Usually requires custom logic
InBe
Built in

Capabilities and commercial terms vary between providers. This comparison describes the typical difference between a general-purpose Places API and InBe's preference-aware venue discovery API.

The cheapest place record is not always the cheapest user experience.

InBe is not trying to win a commodity race for the cheapest raw place record. It's designed to reduce the total cost of reaching a useful answer. Better matching at the start can mean fewer calls, less scraping, less data reconciliation and less product logic to maintain.

Instead of paying to retrieve a pile of possibilities, InBe produces a ranked shortlist around what everyone actually needs. It reduces the need to depend on scraped, fragmented, old, or difficult-to-maintain data sources.

Fedor, CTO, InBe
Fedor SulitskiyCTO, InBe

Every venue. Every detail.

Precision metadata for apps that help people meet, eat and drink.

Venue intelligence

Ultra detailed venue data

Get detailed information about venues, including menus, pricing, ambiance, and more.
Smart matching

Preference driven

Wow your customers with recommendations and information tailored for them.
Multi-location search

Tools for multiple locations. Find restaurants, bars and cafés based on multiple sets of preferences and locations.

In-app experience

Loyal to you

Keep users inside your app by giving them the info they need to make decisions.
Decision support

Built for decision-making

A suite of tools designed to enable you to answer customer needs directly.

Answers, not research homework

Bring venue decisions back into your product.

Open up a new world for your users with InBe's preference-aware venue discovery—built for group venue matching, dietary search, and ranked shortlists.

No card required. Full core API access.

Start building for freeSee pricing & migration

Keep exploring

Questions teams ask

Built for developers who connect people to places

Start buildingExplore the API

Connecting users to real-world places shouldn’t mean stitching geocoding, routing, Places search, and ranking yourself. One preference-aware search replaces the pipeline.

api.inbe.us/v1/search200 OK
POST
{
"locations": [
{ "lat": 51.523, "lon": -0.158, "label": "Alex" },
{ "lat": 51.493, "lon": -0.098, "label": "Sam" }
],
"mode": { "mode": "POINT", "maxDistance": 750 },
"preferences": {
"goodFor": ["date", "cocktails", "conversation"],
"catersFilters": ["vegetarian"],
"establishmentFilters": ["servesCocktails"]
}
}
response
{
"centerPoint": { "Lat": 51.508, "Lon": -0.128 },
"radius": 750,
"establishments": [
{
"displayName": "The Lantern Room",
"distanceMeters": 142,
"matchScore": { "total": 0.94 }
},
{
"displayName": "Barrio Soho",
"distanceMeters": 186,
"matchScore": { "total": 0.91 }
}
]
}

Fair middlegrounds

Multi-person locations in one call; we balance travel so you don’t build routing yourself.

Preferences that actually match

Dietary, vibe, good-for, and constraints as first-class inputs, not post-filters on pins.

Pay for the hard parts

Core search and enriched place data stay cheap; you pay where decision intelligence earns its keep.

Tools for user decisions

Ranked shortlists and experience-ready answers so your product keeps users in-flow, not off to a map.

Illustrative scenario

0ms

Ranked shortlist in one call

Preference-aware search returns a decision-ready shortlist without stacking Places, routing, and enrichment calls.

~15× faster vs multi-call pipelinesNot a live benchmark
RESTWorks with any stack
curl -X POST https://api.inbe.us/v1/search \
  -H "API-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "locations": [
      { "lat": 51.523, "lon": -0.158, "label": "Alex" },
      { "lat": 51.493, "lon": -0.098, "label": "Sam" }
    ],
    "mode": { "mode": "POINT", "maxDistance": 750 },
    "preferences": {
      "goodFor": ["date", "cocktails", "conversation"],
      "catersFilters": ["vegetarian"],
      "establishmentFilters": ["servesCocktails"]
    }
  }'
Full examples in docs

Start in minutes with the knolage you can scale without stress.

Generous free usage to evaluate, startup credits to grow, and a migration path when you are ready to switch from stacked Places pipelines.

Start in minutes

No sales call. Sign in, grab a key, and ship a first search.

Start building

Build — free forever

£10 of usage every month, full core API, no card required.

See Build plan

InBe for Startups

£2,500 usage credit, Grow-level features, and onboarding support.

Startup programme

Switch with confidence

Migration credits from £500, dual-running help, and high-spend matched offers.

Migration programme