Google Places was built for maps. Your product needs answers.

InBetween is a venue API built for plans rather than pins: detailed restaurant, bar, and café data, genuine preference matching, and multi-person search in a single 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 outgrowing generic place data

A different problem needs a different API.

Google Places solves its problem exceptionally well: a pin, a radius, a category, a list of nearby records. That model is superb for navigation. It falls apart the moment a real plan is involved.

Real plans involve people with constraints. Someone is vegetarian, someone is coming from the other side of the city, and the occasion calls for somewhere you can actually hold a conversation. Teams end up chaining requests, filtering on data that is too thin to filter on, and writing ranking logic that never quite feels right.

InBetween replaces that stack with one request. We build detailed profiles of restaurants, bars, and cafés, covering menus, dietary coverage, atmosphere, and the smaller signals that decide whether a place suits an occasion, then match them to the people in the plan.

What breaks today

  • Generic place records are too thin to support real preference matching.
  • Multi-person search means midpoint maths and stacked requests you maintain yourself.
  • Per-query pricing designed for enterprises gets uncomfortable at consumer scale.

What you can ship

  • Answer 'where should we meet?' in one API call.
  • Keep the most engaging moment of the journey inside your product.
  • Scale on credit-based pricing with a free monthly allowance.

How it works for you

  1. 01

    Send the whole plan in one request

    Locations, preferences, hard constraints, and context go into a single call. No midpoint maths, no chained lookups, no custom ranking code.

  2. 02

    Filter on data deep enough to filter on

    Dietary coverage, atmosphere, noise, seating, and price are structured fields, not fragments buried in review text.

  3. 03

    Render a ranked shortlist in your own interface

    We return options you can present directly, so the decision happens inside your product rather than on a map.

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.

A places API built for plans

Make your first search in minutes.

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