diff --git a/documentation/API proposals/APIproposal_QoS_Booking_KDDI. md b/documentation/API proposals/APIproposal_QoS_Booking_KDDI. md
new file mode 100644
index 0000000..1529829
--- /dev/null
+++ b/documentation/API proposals/APIproposal_QoS_Booking_KDDI. md
@@ -0,0 +1,12 @@
+| **Field** | Description |
+| ---- | ----- |
+| API family name | Name of the API or API family |
+| API family owner | Company submitting the API proposal. |
+| API summary | High level description / scope of the API or API family, and two/three examples of in-scope business cases. |
+| Technical viability | Identify the underlying network/cloud capabilities which are needed for the support of this API or API family, relating these capabilities them to standards maturity.
Example: this API requires the availability of NEF with this Rel-15 "X"feature.
+| Commercial viability | Specify the availability of commercial or (industrialized) open-source solutions for the identified network/cloud capabilities.
NOTE: If open-source, provide a publicly available reference/link to the actual solution, and specify the version under consideration.|
+| YAML code available? | YES / NO. |
+| Validated in lab/productive environments? | YES / NO.
If YES, specify if it was lab network or productive network. |
+| Validated with real customers? | YES / NO.
If YES, specify how many customers participated in the evaluation, and what their use cases were.
NOTE: It is not mandatory (though recommendable) to specify the name of the customers. |
+| Validated with operators? | YES / NO.
If YES, specify how many operators participated in the evaluation.
NOTE: It is not mandatory (though recommendable) to specify the name of the operators. |
+| Supporters in API Backlog Working Group | List of supporters.
NOTE: That shall be added by the Working Group. Supporting an API proposal means that the supporting company must provide at least 1 (one) Maintainer at the time of the Sub Project creation. |