Turn "where-to-meet?" moments into engagement.

InBetween delivers ultra-detailed venue data, and group-matching logic that generic map APIs can't support, meaning your users can find a place to eat, drink, or meet without leaving your app.

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"]
}
}

Introducing the next generation of location intelligence

Our platform continuously analyses and interprets real-world places, turning fragmented venue data into a single source of truth for your product.

99.9%

Uptime guarantee for all our services.

24/7

Support available around the clock.

1M+

API requests processed every hour.

500k+

locations and growing by the minute.

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.

Built for a new generation of apps

Triditional place APIs are not fit for the modern world. We created InBetween to help developers and businesses connect digital experiences to the real world.

AI chatbots are transforming customer service, but without accurate data, they fall short. InBetween delivers the intelligence they need.

api.inbe.us/v1/search200 OK
POST
{
"locations": [{ "lat": 51.51, "lon": -0.12 }]
"mode": { "mode": "POINT", "maxDistance": 800 }
"preferences": {
"catersFilters": ["vegetarian"]
"goodFor": ["groups", "cocktails", "conversation"]
}
}
response
"establishments": [{
"displayName": "The Lantern Room"
"distanceMeters": 320
"catersFlags": ["vegetarian", "vegan"]
"matchScore": { "total": 0.94 }
}]
Venue assistant

Restaurant for six after an event?

Veggie options please

Within 10 min of the station

The Lantern Room — quiet, veggie-friendly, ££, 4 min walk, tables for six.

The Lantern Room

Match found

Veggie✓
Quiet✓
4 min walk✓
Tables for 6✓
Case Study

Perfect places

Perfect Places helps friends and groups find venues that work for everyone: fair travel times, real preferences, and the kind of place data you cannot get from a simple location search. InBetween turns a costly chain of map requests into one ranked set of ready-to-use recommendations.

The Challenges:Why place discovery gets expensive fast

For Perfect Places, the hard part was not showing a map. It was calculating the best middle ground, checking whether each venue actually fits the group, then returning useful results quickly without stacking up API calls.

Meeting InBetween everyone

With traditional maps APIs, every extra person means more geocoding, routing, travel-time checks, and custom ranking logic before you even know where to search. InBetween handles the location balancing up front.

Alex
veganquiet
Sam
cocktails££
Jordan
latedates
Merged request1 call
veganquietcocktailsdates

Filtering for what people actually need

A good result is not just nearby. It might need gluten-free options, a quiet atmosphere, wheelchair access, or late opening. InBetween returns places matched to the real-world requirements.

Places APIRaw records
+12 fields enriched
InBetweenRanked answer
menuvibedietary★ 4.8

Returning answers, not raw place records

Google Places gives useful basics, but not menus, nuanced preferences, venue capabilities, or deep context by default. InBetween gives ranked options with richer data already attached.

Built for what users actually need

PerfectPlaces keeps the product, the UI, and the relationship with the group. InBetween sits behind their servers as a single integration that finds fair middle grounds, matches real preferences, and sends back ranked places ready to show.

InBe has been a user experience superpower. It enables us to deliver a fantastic experience, whilst cutting our API costs by two thirds.

Jordan Salway, Product Lead, Perfect Places
Jordan SalwayProduct Lead, Perfect Places
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

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

Get the latest

Product updates, engineering notes, and ideas for building with location intelligence.

View all posts