---
title: 'How to Create a Laravel API: Explained in 14 Minutes'
source: 'https://youtube.com/watch?v=WVNiiov53CE'
video_id: 'WVNiiov53CE'
date: 2026-06-15
duration_sec: 869
---

# How to Create a Laravel API: Explained in 14 Minutes

> Source: [How to Create a Laravel API: Explained in 14 Minutes](https://youtube.com/watch?v=WVNiiov53CE)

## Summary

This video provides a concise 14-minute overview of creating APIs in Laravel, covering setup, routing, controllers, Eloquent API resources, pagination, CRUD operations, validation, HTTP status codes, and Laravel Sanctum authentication. It's a shortened version of a full course, aimed at beginners.

### Key Points

- **Enable API in Laravel 11** [00:50] — Laravel 11 does not include API routes by default. Run 'php artisan install:api' to enable them, which also installs Laravel Sanctum and adds the HasApiTokens trait to the User model.
- **Returning Data with Eloquent API Resources** [01:57] — Use 'php artisan make:resource CategoryResource' to create a resource class that controls which fields (e.g., id, name) are returned. Wrap the collection in the controller using 'CategoryResource::collection(Category::all())'.
- **Pagination with Eloquent** [03:45] — Replace 'all()' with 'paginate(2)' to get paginated results. Laravel automatically adds 'links' and 'meta' fields for pagination metadata.
- **Full CRUD with API Resource Routes** [05:24] — Use 'Route::apiResource('categories', CategoryController::class)' to generate five routes (index, show, store, update, destroy). Store returns 201, update returns 200, destroy returns 204 with no content.
- **Accept Header for JSON Errors** [08:14] — Always send 'Accept: application/json' header in API requests. Without it, Laravel may return HTML error pages instead of JSON.
- **Validation and HTTP Status Codes** [08:38] — Validation errors return 422 with error details. Server errors (e.g., missing validation) return 500. Use correct status codes: 2xx success, 4xx client error, 5xx server error.
- **Laravel Sanctum Authentication Overview** [11:38] — Sanctum supports three modes: API tokens (for separate frontends), SPA cookie-based auth (same domain), and mobile tokens (with device name). All use the 'auth:sanctum' middleware.

### Conclusion

This video covers the essential steps to build a Laravel API, from setup to authentication. For deeper topics like file uploads, versioning, and testing, the full course is available.

## Transcript

Hello guys, how to create APIs in
Laravel. There's no specific
documentation section for that. There's
no specific starter kit in Laravel. So I
decided to give an overview in this
video in roughly 14 minutes or so to
help you get started with fundamentals
of APIs. This will be a shortened
version of the fundamentals of my new
updated course on Laravel API from
scratch. So I reshot the videos, the
video version. So all the lessons are
video plus text. So the whole course is
1 and a half hours plus some text
lessons. But in this video I will try to
summarize the main things that you need
to know in 14 minutes. But if you want
the full course the link will be in the
description below. Let's dive into
creating APIs. The first thing you need
to know is when you install the Laravel
project, there's no API by default. So
if you run Laravel new, none of the
starter kits are for API projects. So
you choose none and then you install API
separately. Enable that functionality
because it's not enabled by default
since Laravel 11. So after that
installation, if we go to the source
code, there's no routes API file.
There's only routes web. So you need to
enable the API. By default, Laravel
assumes that you don't have API and you
don't work with API. So you need to run
PHP artisan install API which will do
two things. install Laravel Sanctum
which we will later use for
authentication including the migration
for the tokens but also what is more
important I'm sure if you noticed on the
left now we have routes API file and the
final thing to do with that installation
is add Laravel Sanctum has API tokens to
user model again for later
authentication but in the routes now we
have routes API where exactly we will
put our routes for this video but to
finish the installation in the user
model let's have has API tokens which is
autocompleted by my cursor like this.
Next I will show you how to get the data
via API. So this is the database table
of categories and we will create a route
and a controller to get that with the
API call. So we make the controller I
specifically specify namespace from the
very beginning and then in the routes
API we do route get categories
controller with index and controller is
used on top but in fact it's not correct
autocomplete. It's this. Now in that
category controller in the index method
all you can do is just return eloquent
collection and then Laravel will take
care of returning that as JSON. So in
your API client like Postman for
example, you can just launch the URL
which is powered by my Laravel herd the
API is the default prefix of all URLs in
routes API file and you just launch get
request and get the list of categories
with all the columns as they are from
the database. But in real projects you
probably want to customize the columns
that are returned. For example, return
just ID and name and not the timestamps.
For that usually in Laravel people use
so-called eloquent API resources. So we
run artisan command make resource with
model name resource and then it
generates the file category resource
which should return the array by default
parent to array but this is where we
override the defaults and return what we
want to return from that category model.
So for example, we want to return this
ID, then this name and timestamps. And
in this case, we don't want to return
the timestamps at all. So let's leave it
like this. And then in the controller to
enable that eloquent resource, we wrap
our category all into collection, which
should be also added in the use section
on top like this. Now if we launch our
postman, the same URL, I don't change
anything. I just relaunch. We have this
changed in fact two changes. First we
return only what is specified in the API
resource but also we have a new wrapper
layer called data which is closer to
general API standards on the market
outside of Laravel because there may be
additional stuff in addition to data
like pagionation like other related
resources and stuff like that. But if
you want you may disable that in your
app service provider of Laravel project
in the boot method you may specify JSON
resource without wrapping like this. And
now if we relaunch the same request we
don't have that data but personally I
wouldn't advise that this is kind of a
standard and it's generally good to use
market standards for the future. And let
me show you that pagionation in action
that I mentioned. So all you need to do
to use pagionation from eloquent is
change all to for example pagionate by
default pagionate by 15 but we have only
three records in the database. So we'll
do pagionation by two records and that's
all we need to do again laravel will
take care of providing the structure and
the fields automatically and let's
relaunch that and see what happens.
First we have the same data but as you
can see two records only and then this
is the reason why the data separately is
useful. On top of data in addition to
data you have links to all the pages you
have meta data how many pages are in
total what are the links for pages the
link for next page and other settings
related to pagionation. Next, I will
show you the full crud of API based on
the categories. And I already prefilled
the code to save you some time. So to
show a specific category, you just
return the resource of that category.
And this is where category source is
useful because it's reusable. So when
you launch get with categories ID1, this
returns ID and name only. And this is
all powered by route resource or in fact
separate. There's route API resource
which covers five methods instead of
typical seven because APIs don't need
create form or edit form. So there's
only five methods index, show, store,
update, and destroy. So I showed you how
show works for store method. It's a
typical Laravel thing. So if you worked
with web Laravel, it's nothing really
different. The difference is what you
return. So you create the category, you
validate the category and then return
what if you use the same again eloquent
API resource with new model created or
updated model then again the structure
is similar. So if you do the post
request to add new category, you send
the body name as new category. For
example, we send and we get the data
again with ID and name using Eloquent
API resource. And by default for this
case for create Laravel returns 201 HTTP
status code instead of just 200 which is
in the same 200 success status codes.
And this is probably the most important
part of working with APIs in general
using correct HTTP status codes or at
least the first number of two which
means successful. And we'll return to
status codes in a minute. For now I want
to show the full CRUD. So this is what
happens when you create a new category.
Then for patch request or put it's
almost the same put or patch. Then you
do ID here and then you pass the name of
updated category for example. Then you
send and then it returns the updated
category but this time with 200. Okay.
And then finally destroy method. This is
kind of interesting. So what do you
return after there is no record in the
database. It's deleted. Typical thing
how developers return data here is
response no content which would return
status code 204. still two as the first
number which means success but no
content will be returned which is
probably a good indicator for the front-
end client that well there's nothing to
show. So if we delete the category
number three for example, we don't need
any body in this case. But if we even
pass that, it wouldn't be counted. We
send and as you can see no content here.
204 status code here. And if we try to
get that category by ID, we would get
404 not found. Which leads me to another
tip. If you get HTML as a result, it
means that you didn't pass important
header. So in the headers of your API
client whichever you use you do need to
pass accept application JSON then if you
get any error you get that error in JSON
which is friendly for API client in
JavaScript or whichever front end you
have. Next let's talk about validation
in Laravel and this is where we will get
back to HTTP status codes. So what
happens if we don't pass the name which
is required. So in the controller we
have request form request which has that
rule of validation. By default Laravel
in case of validation error will return
422 status code and will provide the
list of errors related to those fields
automatically forming the error messages
similarly how it would do on the web
just in JSON structure for the API. And
this is okay this is how it's supposed
to work. So your API client would see
422 status code and the first digit four
means that the error is on the client
side. So some data or some request
didn't go well. So they need to fix the
error on the front side like pass
different data or pass different
endpoint or something like that. But if
you don't do the validation on the
Laravel layer for example, let's remove
that validation rule which would lead to
SQL query being executed which will fail
because on the database level that
category name is required which then
will lead to if we send 500 internal
server error. And of course for
production APIs you would have appV
production so they will not see the SQL
error because otherwise it would be a
security issue. But generally when the
API client sees 500 error or five
whatever then means the error is on the
server side. So the front end would need
to report to you and you need to fix the
error. So it's your job as a backender
to do something like this. What I'm
saying here is that 400 and 500 status
codes are all errors but different in
what should happen after that error. And
the list of available HTTP status codes
is pretty huge. You can find them on
Wikipedia. So there's 200. Okay, we saw
that 200 created and others, but
probably you will use in your Laravel
projects only a few of them. So I found
this shorter list in Laravel docs for
HTTP client which works with external
API and these are the codes generally
accepted which have specific methods
which means that those are probably kind
of the most probable HTTP status codes
to happen. So you need to learn at least
those. What do they mean and in what
cases do they return these codes? But
the basics of HTTP status code is this.
I wrote an article on Laravel Daily.
This is for premium members. But I will
show you the point number one. The worst
practice of API is returning 200 status
code. If there is an error, you need to
always rely either on Laravel automatic
validation mechanism or specifically
return 4 to2 or 500 whatever is the
actual error. There's a classical meme
about it and I found the original on
Reddit here. So this is kind of the API
client happily receiving the message but
then inside of that message it says
error. Finally in this video I will talk
about Laravel Sanctum which is in itself
a huge topic. So I will just give an
overview from the doc. So you would
understand the concept because how you
use sanctum depends on what front end do
you use it from. And in the course I
have a separate big section with
potentially most popular front ends
Vue.js next and mobile flutter react
native with repositories how you would
use Laravel Sanctum for those. But in
this video as an overview so you would
understand the concept. If you use
Sanctum for API token authentication, it
probably means that you have front end
separate like JavaScript application
like Vue.js or any JavaScript which
calls Sanctum to get the API token. This
is where use has API tokens from user
model is useful and you have a specific
route to generate the token and return
it to the front end and then all the
requests from there from the front end
should contain that token for
authentication. And then in your routes
you use middleware o sanctum which would
check that token. Then the second way
how you would use Laravel Sanctum is for
so-called SPA single page applications
which don't use any token and instead
uses Laravel builtin cookie. So that is
a separate topic. You need to configure
domains. You need to configure
middlewares and then for authentication
you need to get so-called CSRF cookie
and then configure some more stuff. But
at the end in the routes, it's still
middleware of sanctum. Similarly how you
would use it in the first way. And then
the final way is for mobile application
authentication. It's almost the same as
the first way. You issue tokens, but in
this case you also have the request
device name for example to assign the
token to specific mobile device of the
client. And then that mobile device
should pass the token as bearer token
and authorization header. And on the
back end, same thing for protecting
routes. In all those cases, it's
middleware of sanctum to the route or to
the route group. So yeah, this is the
basic concept of how you use sanctum and
the basic concept of how you use API in
general. And this is where I will end
this video. So the goal of this video
was to get you started with the
fundamentals of API. So you can go and
create your APIs. You have enough
knowledge. But if you want to get deeper
and more practical again with Sanctum,
separate examples also talking about
uploading files and other features like
documentation, versioning, rate limits
and unit testing. I invite you to get
the full course available for Laravel
Daily Premium members as well as 80
other courses at the moment. The link to
that course will be in the description
below. But if you have any more
questions about APIs which I should
touch in separate videos here for free
on YouTube, let me know in the comments
and let's discuss. That's it for this
time and see you guys in other