Full Featured HTTP API

Hey Developers,

We just released a new Lua API for sending HTTP requests! It is much more powerful and will allow you to use a wider variety of web services. Here are some details on how it is better than our previous API:

Unrestricted HTTP Methods & Content Types
You are no longer limited to a whitelist of request methods (GET, POST) and encodings (JSON, XML, form, plain text). You can now use all HTTP methods and data types.

Full Response Data
Before you could only get the response body. Now you can get all response data, including status code and response headers.

Extensible API
We had trouble adding options to the previous API because of how it was structured. I designed this new API from the ground up to ensure that it would be flexible enough to support all future additions.

See the docs for more information: HttpService:RequestAsync

Let us know what you think and what additional features you want from our HTTP API!

136 Likes

Is it strictly impossible for this API to throw a Lua error (i.e. do we not need to pcall it ever)? If not impossible, which cases would cause errors?

7 Likes

Yes! Yess! Finally I have been waiting so long! Great job guys. :+1:

2 Likes

@buildthomas See the API reference page for answers to your questions.

1 Like

I have, as far as I know it does not answer my question. I understand fully well it returns status code and other status information, but I’m just asking for confirmation that it really never does throw a Lua error for any kind of reason (apart from input parameters being incorrectly typed).

It doesn’t specify so on the developer hub and it would make it different from all other --Async methods, which is why I’m asking to be sure.

1 Like

It can still error if your parameters are invalid (e.g. invalid method, unsupported header key, etc.) or if network error occurs - basically when there’s no valid StatusCode to return. So you have to pcall it.

18 Likes

This is great.

Now if only we had a higher rate limit than 500… :heart:

6 Likes

YES YES YES YES YES YES YES…
inhales
YES YES YES

But seriously this is a big improvement to the httpservice. Thank you!

5 Likes

Previously this was able to access the roblox.com website and send requests to it, is this still a thing or was that temporary?

7 Likes

Thank you. It’s really great to have a feature request met so fully.

2 Likes

This is sooooooo cool! Thanks!

I love this feature, Trello users have been waiting this for a long. Useful for apis and webhooks :heart_eyes:

1 Like

me right now

4 Likes

thankyouthankyouthankyou

Just checked this, we can’t access roblox.com URLs anymore.

:confused: awww

Still great feature though ! Ty ty!

1 Like

Oops it looks like the documentation that’s live isn’t the latest draft – I’ll make sure to get it updated. The answer is yes, the method will throw if a response isn’t successfully received.

Edit: The updated documentation is live.

3 Likes


@Maximum_ADHD On API page on the wiki, this paragraph is repeated twice (one before the example code and one after the example code).

1 Like

That was a bug. We cannot allow you to send requests to roblox.com until we figure some things out to prevent possible abuse vectors. Long term we want to enable this so you can use all of our APIs, not the just ones we expose to our Lua API.

15 Likes

:tada: Finally!

Since the 343 release notes (which needs to be updated to show that the update is live), I’ve been looking forward for this more or less daily. Awesome to finally see it shipping! :smile: IsHttpServiceRequestAsyncEnabledPlease.rbxl (12.3 KB)

Well, time to make modules for just about any webservice (or just most-relevant use-cases, ha).

1 Like