OpenTable is built for diners. Your product needs answers.

InBetween is a venue API for apps that today hand users off to booking destinations: deep restaurant data, preference matching, and multi-person search in one request.

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 lose users at the handoff to booking apps

A destination app solves a different problem.

OpenTable does its job exceptionally well: help a diner find a table and book it. That model is superb when the user is already in a booking mindset. It falls apart the moment the intent starts inside another product.

Dating apps, messaging platforms, travel guides, and AI assistants create the desire to meet. Then, at the decisive moment, many of them push people out to a consumer destination to finish the job. The product loses the most valuable part of the journey, and the user does research a computer should be doing for them.

InBetween replaces that handoff with infrastructure. We profile restaurants in depth, match them to the people and preferences in the plan, and return a ranked shortlist you render in your own interface — so the decision stays where the conversation started.

What breaks today

  • Handing users to a consumer booking app leaks engagement at the moment that matters most.
  • Marketplace UIs are not designed for multi-person plans or product-specific preferences.
  • You cannot deeply customise discovery when the search lives on someone else's destination.

What you can ship

  • Resolve restaurant decisions inside your product instead of after a handoff.
  • Present options that fit the group, not just whatever is bookable nearby.
  • Stay the brand your users trust for the whole journey from intent to place.

How it works for you

  1. 01

    Keep discovery inside your product

    Send locations, preferences, and constraints in one request. Users never leave your flow to finish 'where should we eat?'.

  2. 02

    Match on more than availability

    Dietary coverage, atmosphere, price, and occasion suitability are structured fields — not something left to a booking marketplace UI.

  3. 03

    Own the experience end to end

    We are infrastructure, not a destination. You decide how results look and feel; booking can sit on top when you are ready.

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.

Keep the journey in-app

Stop losing users at the booking handoff.

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 freeExplore the API

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